Delays runon bash launch replies until the remote runner confirms capture of its inputs, so callers never receive a task_id before the input files are copied.
The reply waits for the runner's first Accepted record or a settled refusal, staying pending across retries, drain signals, and cancellations without shortening blocking waits; a signal or expired deadline that lands after Accepted still returns the ordinary launch reply (or a recorded refusal's error), not the pending one.
The wait shares a 60-second deadline with the call's timeout budget; on expiry the reply returns the task_id with a warning that input files must stay untouched until the job is queued or running.
Snapshots report a "submitting" phase until acceptance instead of showing a not-yet-accepted job as queued or running; a task that settles before acceptance returns its saved outcome with advice (no in-flight warning), an accepted-and-finished task keeps its ordinary launch reply, and only live tasks carry the input-safety warning.
Capture-pending state is persisted in snapshots, so an AFT restart or disk recovery keeps the delayed reply and warning instead of handing back the task_id mid-capture, and capture-state reads honor a recorded Accepted even when they start after the deadline.
Terminal-status checks and live runon handoff tracking are centralized in the bridge for consistent plugin behavior; OpenCode and Pi extend their runon transport deadline so the delayed reply is not discarded, while local and legacy remote launches stay unchanged.
Tool schemas tell agents not to change or delete files a background command uses until it finishes.
Confidence Score: 5/5
The changes since the previous review appear safe to merge.
Summary
Delays explicit runon launch replies until the runner confirms input capture, with a warning when capture remains pending.
Runon launches wait for the runner to capture their inputs.
Task status shows when the runner is capturing inputs.
OpenCode and Pi track runon tasks from their first reply.
Bash guidance tells agents to leave background command files alone.
Diagram
%%{init: {'theme': 'neutral'}}%%
flowchart TD
A[Explicit runon launch] --> B[Wait for input capture]
B --> C{Saved task state}
C -->|Accepted without refusal| D[Ordinary launch reply]
C -->|Refused| E[Return refusal]
C -->|Ended before acceptance| F[Return saved outcome]
C -->|Still pending at deadline or drain| G[Task handle with input warning]