[Feature] Live mid-run steering of a running Workflow: hot-reload the already-persisted script + signal in-flight agents to re-read settings (change model/effort/prompt, inject agents) without a stop→resume cycle

[Feature] Live mid-run steering of a running Workflow: hot-reload the already-persisted script + signal in-flight agents to re-read settings (change model/effort/prompt, inject agents) without a stop→resume cycle

Summary

A running Workflow is effectively frozen: you can pause, stop, restart an agent, or resume, but you cannot adjust an in-flight run — you can't change a running agent's model/effort/prompt, edit the root orchestration prompt and have it take effect live, conveniently inject extra agents, or send a steering message to a workflow-spawned agent.

The key observation: the state is already on disk. Every run persists its script to a file under the session directory (~/.claude/projects/<session>/…, path returned by the Workflow tool), and each workflow-spawned agent has its own agent-<id>.jsonl transcript plus a shared journal.jsonl. So the missing capability isn't persistence — it's a live re-read + steer path on top of persistence that already exists.

Current behavior (verified)

Interactive controls (/workflows): p pause/resume · x stop agent or whole run · r restart an agent · f filter · Enter drill into an agent (prompt, tool calls, result) · s save script as a command.

The only way to change behavior today is a stop → edit script on disk → relaunch with resumeFromRunId cycle: the unchanged prefix of agent() calls returns cached results instantly, and everything from the first edited/new call onward runs live. This is powerful but it is a restart cycle, not live mutation — an agent already in flight never re-reads a changed prompt/config.

No live steering of workflow agents. Unlike top-level Agent-tool agents (addressable, continuable via SendMessage) and Agent Teams (inter-agent messaging), agents spawned inside a Workflow are orchestrated by the deterministic script and are not individually messageable mid-run.

Gap table

| Capability | Today |
|---|---|
| Change a running agent's model / effort / prompt mid-flight | ❌ |
| Edit root/orchestration prompt and have it apply to the in-flight run | ❌ (only via stop→resume) |
| Inject additional agents into a running run not originally scripted | ❌ |
| Send a steering message to a workflow-spawned agent | ❌ (works for Agent-tool / Agent Teams, not Workflow agents) |
| Persisted script + per-agent transcript on disk | ✅ (already exists — the foundation to build on) |

Proposed behavior

Build a live-adaptation path on top of the persistence that already exists, rather than requiring a stop→resume cycle:

1. Hot-reload the persisted script / per-agent override. The runtime accepts an edited script file (or a per-agent config override) and applies it to the in-flight run — for agents not yet started it just uses the new config; for the orchestration going forward it uses the new logic. (Generalizes today's resumeFromRunId from "stop then relaunch" to "apply without stopping.")

1. Signal an in-flight agent to re-read. Deliver a "your settings/directive changed — reconsider" signal to an agent that is currently running (change its effective prompt/model/effort at a safe turn boundary, or hand it a mid-course correction), analogous to SendMessage for Agent-tool agents. This is the user-proposed mechanism: the initial message is already stored as a file, so replace the file and notify the agent of the new settings so it re-reads them.

1. Convenient mid-run agent injection. A first-class way to add agents to a running run (e.g. "spawn N more finders in the current phase") without hand-editing the script and doing a full relaunch.

Semantics to define (open for discussion):

• Safe apply points — mutations take effect at turn/phase boundaries, never mid-tool-call, to preserve determinism guarantees and cached-prefix integrity.
• Scope of a change — per-agent override vs. whole-script hot-reload; which already-completed results stay cached.
• Auditability — record what was changed live and when, so a long autonomous run stays reproducible/explainable.
• Relationship to resumeFromRunId — this extends it (live apply) rather than replacing it.

Why this matters

• Long autonomous runs can be course-corrected without throwing away cached progress or killing the run.
• Control + convenience: tweak a misbehaving agent's model/prompt, or fan out more workers, the moment you see the need in /workflows — instead of stop → edit → relaunch.
• Parity: brings workflow-spawned agents closer to the live-steering that Agent-tool agents and Agent Teams already enjoy, while keeping the deterministic-script model.

Out of scope / already covered

• Asynchronous waiting for agent responses is already supported (background runs, parallel()/pipeline(), /workflows monitoring) — not requested here.
• Complements #74142 (per-agent / per-phase goal): goals define when a unit is done; this request is about adjusting units while they run.

Environment

• Claude Code Workflow tool (agent() / parallel() / pipeline() / phase()), /workflows run view, resumeFromRunId resume mechanism.