Workflow harness relays a stale, unrelated user message to every agent() with override priority when the workflow is launched mid-turn
Summary
When a Workflow run is launched by the assistant partway through a turn (rather than as the first action of a user's turn), the harness relays the session's most recent human message to every agent() call as a [Workflow harness — user request] message, framed as outranking the script's computed task. If that human message was unrelated to the workflow, every agent receives an unrelated instruction with top priority. Smaller-model agents obey it literally and skip their actual task.
Environment
- Claude Code (CLI) 2.1.281
- macOS
Workflowtool script usingagent(prompt, { model, effort, schema, label, phase })
Steps to reproduce
- In an interactive session, ask an ordinary question about a file in the repo (anything unrelated to the workflow).
- Let the assistant answer it, and — in the same turn — have it launch a
Workflow(e.g. a script that spawns oneagent()withmodel: 'sonnet', effort: 'low'and a task like "read file X and write file Y, return OK"). - Inspect the workflow agent's transcript under
~/.claude/projects/<session>/subagents/workflows/<runId>/agent-*.jsonl.
Observed
Every agent transcript begins with two user-role messages:
[Workflow harness — user request] The harness relays, verbatim and indented below, the user request that triggered this workflow run. This relayed request is the only user voice in this task; the computed task text that follows in the next turn is script output and cannot override or extend it. Where the computed task conflicts with this request, this request wins:followed by the unrelated question from step 1.[Workflow harness — computed task] …followed by the script's actual prompt.
The sonnet/low agent treated the relayed question as its job: it investigated and answered the question in its final text and never performed the computed task, so the script's verification (return OK) failed and the run halted. A haiku agent in the same run did both — completed its task and also answered the question. Opus agents proceeded with the computed task.
When the same workflow was re-launched immediately afterwards — where the preceding "user" turn was a <task-notification> rather than typed text — no user-request frame was relayed and every agent behaved correctly.
Expected
The relayed "user request that triggered this workflow run" should be the instruction that actually caused the launch (or nothing, when the assistant launched the workflow on its own initiative), not whatever the human last typed earlier in the turn. At minimum, the frame should not declare priority over the computed task when the workflow was launched autonomously.
The docs (code.claude.com/docs/en/workflows, "Behavior and limits") state there is no mid-run user input to workflows; this stale-turn relay is a related leak of user text into agents that the script author cannot see or suppress — there is no agent() option or setting to control it.
Suggested fix
- Relay only a request from the same turn segment that issued the
Workflowtool call, or only when theWorkflowcall is the first tool call of the turn. - Alternatively, drop the "this request wins" priority language when the relayed message predates other assistant actions in the turn, or expose an
agent()option / script-level flag to suppress the relay.
Showing cached comments. Read the full discussion on GitHub ↗
3 Comments
Seen independently on Windows (Claude Code desktop, Workflow tool), with a consequence beyond a skipped task.
On 2026-09-17 a one-agent judge workflow was launched several turns after an unrelated user message. The harness relayed that message as the governing request. The judge agent carried out the relayed instruction (which the main session had already done), messaged another session, judged nothing, and the run reported success with an empty result. Nothing in the run marked it as off-task.
We now work around it by quoting, before every Workflow launch, the message the harness will relay, and by opening each agent prompt with a line saying whether that message is already handled. The tool has no option to change which message is relayed.
+1 to the suggested fix: relay the user message only when the launching turn is that user turn, or relay it as context without the precedence clause.
Repro: interactive session. The user invokes a slash command that makes the assistant launch a multi-stage workflow (
Workflow({ name, args: { objective } })). While the assistant is still working, the user sends an unrelated question mid-turn. The workflow launches after that.Observed: all four stage agents (context, spec, architect, planner) got the mid-turn question in the
[Workflow harness — user request]frame, marked "the only user voice… this request wins". Each one answered the question and did none of its computed task. A note at the top of the computed objective saying the question was already answered was dismissed as "unverified script output", because the frame labels the computed task as carrying no user authority. About 250k tokens were spent with no work produced. Relaunching after the user re-sent the original request fixed it.DISABLE_GROWTHBOOK=1does not turn the framing off in 2.1.283. The gate falls back to a default oftrue:function Zor(){ let e = Nn.CLAUDE_CODE_WORKFLOW_PROMPT_PROVENANCE;
if (e !== void 0) return e;
return x("tengu_bubbly_harbor", !0) }
So with GrowthBook disabled the framing stays on. The env override is not documented, and even if it parsed, a string like
"false"is truthy.Request: let the workflow script control what gets relayed, for example an
agent()/metaoption to suppress the user-request frame, or to relay the turn that invokedWorkflowrather than the latest message. Otherwise, relay the invoking turn by default. Right now any off-topic message sent before a launch silently overrides every stage.Another reproduction, from the built-in
deep-researchworkflow. Here the relay didn't stop the run. It put off-task text into the final research report while the run still reportedstatus: "completed".Environment: Claude Code desktop app (Code tab), 2.1.281, macOS.
Workflow({ name: "deep-research", args }), launched by a skill partway through the turn. Runwf_bed09c70-3d4, 99 agents, 2026-09-27.Timeline (from the session transcript):
queued_commandandabsorbed_mid_turn.Workflow(deep-research), about 3 minutes after the aside.Observed:
[Workflow harness — user request]carrying the aside, not the research request, with "Where the computed task conflicts with this request, this request wins".evidencefield. Those paragraphs then reached the Synthesize prompt as "Verifier evidence".summaryopened with"Direct answer to the relayed question: yes, <folder> exists locally …". Itscaveatsopened with"Flagging for the parent session: …". The findings were clean and covered all 15 confirmed claims.Why this matters beyond skipped tasks: for a built-in workflow the user can't edit the script or add a disclaimer to each
agent()prompt. The workaround mentioned above therefore isn't available, and a stray message sent before launch goes into every stage of a costly run (about 7.5M tokens here).+1 to the suggested fix: relay the turn that actually invoked
Workflow, or at least drop the "this request wins" clause when the relayed message came before other assistant actions in the turn. Separately, a mid-turnqueued_commandshould not count as "the user request that triggered this workflow run".