No detached run mode: --local-agent binds the agent worker to the invoking terminal

[khaliqgant]

Problem

There is no way to start a run and walk away. The flag set is:

flows run [--json] [--no-spawn] [--no-observer-link] [--data-dir <dir>] [--local-agent] [--reuse-from <run-id>] <flow>

No --detach, no --background.

This is specifically awkward because the engine is already built for
durability. relayflowd is a daemon and it owns run state: on one machine we
found 35 daemons alive, several for 3+ days, holding 106 completed and 44
failed runs. The run survives a closed terminal today.

What does not survive is the --local-agent worker, which lives in the
invoking process. Close the window and the worker dies mid-step; the run parks
again with no worker is attached for step type "agent".

So the durability story is half-built: the journal is detached from the
terminal, the worker is not.

Why the workarounds are unsatisfying

• nohup flows run --local-agent ... & works, but gives no handle for
  inspecting or steering the run afterwards.
• tmux new -d -s flows '...' works and is what we settled on — but on macOS
  it has to be started from a GUI session, because a tmux server started over
  ssh inherits the ssh session's security context and the agent CLI then cannot
  reach the login keychain. That is a real constraint a user has to discover by
  hitting it.
• --cloud exists but is a different execution surface with its own setup.

None of these are discoverable from flows run --help.

Proposals

1. flows run --detach — start the run, print the run id, exit 0. The
   daemon already owns the journal; this needs the local worker to be
   supervised rather than inline.
2. A supervised local worker, so --local-agent does not imply
   "tied to this tty". Something like flows worker start [--data-dir <dir>]
   that registers a worker the daemon can hand agent steps to, and
   flows worker stop. Then flows run needs no worker flag at all and a
   parked run resumes the moment a worker appears.
3. At minimum, make the park message actionable. It currently says to
   re-run with --local-agent. It could also say that the worker will be bound
   to that terminal, and point at whatever the detached option is.

(2) is the real fix: it separates "who executes agent steps" from "who typed
the command", which is the same separation the daemon already made for run
state.

Impact

Any flow with agent steps that runs longer than someone wants to babysit a
terminal — which is most of them. This is the third time one campaign has hit
the local-agent binding.

[khaliqgant]

Ran a real flow against this and hit two behaviours sharper than what the issue
originally described. Both are throughput/liveness, not just ergonomics.

1. --local-agent services ONE agent step, then detaches

A flow with four agent steps, all dependsOn: [setup] so the DAG permits
full fan-out:

flows run --local-agent flows/audit/delivery-phase0-review.flow.yaml
...
PARKED [run_parked] Run "01M30YRMHXA4A1R7R9N3RX9NSF" parked at step
  "review-contracts" (agent): no worker is attached for step type "agent".
RUN 01M30YRMHXA4A1R7R9N3RX9NSF parked (1 step)

One agent step completed (10 minutes, producing a 26 KB artifact). The other
three never started. ps during the run showed exactly one claude -p
process at a time, so the declared parallelism was never available.

2. flows resume --local-agent <run-id> does not re-attach a worker

flows resume --local-agent 01M30YRMHXA4A1R7R9N3RX9NSF
...
PARKED [run_parked] Run "01M30YRMHXA4A1R7R9N3RX9NSF" parked at step
  "review-contracts" (agent): no worker is attached for step type "agent".
RUN 01M30YRMHXA4A1R7R9N3RX9NSF parked (2 steps)

Zero progress, no new artifacts, parked again immediately — and the parked
count went 1 → 2. So the documented recovery for a park does not recover this
park. With --local-agent being the only local worker mechanism, a flow with
N agent steps appears to need N invocations, and resume is not one of them.

Why this makes the case stronger than "detached mode"

The original issue framed this as durability — you shouldn't have to keep a
terminal open. The harder cost is that a flow can declare parallelism the
runtime cannot use, so the DAG is advisory under --local-agent. Four
independent 10-minute reviews that the graph says are concurrent take 40
minutes serially, if they can be made to run at all.

That is an argument for the supervised-worker proposal in the issue body
(flows worker start, N workers, daemon hands out agent steps) over a simple
--detach flag. A detach flag would fix the terminal problem and leave both
of these untouched.

Suggested acceptance criteria

• A parked-for-no-worker run resumes and completes when a worker is available,
  via flows resume.
• Independent agent steps run concurrently up to the number of attached
  workers.
• If a single local worker is genuinely one-shot by design, flows run
  should say so up front rather than parking after the first step.