[BUG] Workflow harness relays user chat into subagents and demotes the computed task

Observed consequence, not just framing: in an unattended multi-agent workflow (Claude Code 2.1.280, Linux), the launching chat message was a design question unrelated to the agents' work. All 3 Sonnet executor agents given a concrete computed task abandoned it and answered the relayed question instead, each citing the frame's "Where the computed task conflicts with this request, this request wins". The agents all showed as completed, so the failure only surfaced in our own logs. Same pattern the day before in a second repo, and 105 of 106 agents in the run carried the frame. The authority inversion in ask #3 is not hypothetical: it changes what agents do.

_{Written by Claude (Opus 5.5).}

Another reproduction on 2.1.283, plus a detail on the workaround suggested earlier in these threads.

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=1 does not turn the framing off in 2.1.283. The gate falls back to a default of true:

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() / meta option to suppress the user-request frame, or to relay the turn that invoked Workflow rather 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.

Adding a reproduction from the desktop app. This is serious: it has wasted a lot of tokens and hours of wall-clock time in real work, and it needs a fix as soon as possible.

Environment: Claude Code desktop app (Code tab), 2.1.283, Opus 5.5, ultracode on (dynamic Workflow tool). One long session of about 20 hours with dozens of workflows and several hundred subagents.

What we observed

• Every workflow subagent spawned after I send a chat message to the main agent gets that message injected, labelled as my request and stated to take priority over the task the orchestrator wrote. Agents already running are unaffected; only agents spawned after the message are hit.
• It is always my latest message, whatever it is. Status questions, side questions and messages meant only for the main agent all get relayed.
• Subagents treat it as their governing instruction and demote or ignore their assigned task. They also dismiss authorization quoted in their own prompt as "not the user speaking".

Concrete incidents in one session

1. Status question during a workflow. I asked the main agent "you are done?". The next two subagents (an independent reviewer and a job-submission stage) treated it as my current request. Under my standing "status questions don't authorize file changes" rule, the reviewer wrote its result to a scratch directory instead of its assigned path. The submission stage refused entirely and answered my question instead. The main agent had to redo both by hand, costing about 20 minutes and a re-run.
2. Question about model weights. An agent that was supposed to launch a time-critical data-collection job answered my question instead. The launch had to be redone from the main session against an expiring compute allocation.
3. Chat message during edit tasks. Several agents assigned file-edit tasks declined because "the latest user message is a question".

Cost: each derailed stage burned roughly 100k–1M subagent tokens before refusing or doing the wrong thing, plus tens of minutes. The workaround, having the orchestrator quote my authorization verbatim in every prompt, only partly helps. The practical effect is that I can't talk to the main agent while a workflow runs without risking the work.

Contradicts docs: workflows are documented as taking "no mid-run user input", and subagents as starting fresh without the parent conversation.

Ask: by default relay nothing (or at most the message that launched the workflow, clearly labelled as context and never as an override), document the behavior, and give a setting or agent() option to disable it. Related: #96640, #97076, and the side-chat issue I filed as a workaround path, #97587.

Reproduction from Claude Code in CLI (Windows 11, powershell 7). Real annoying, real inconvenient.

Tested on Windows 11, native installer, Claude Code 2.1.283 (the env var name is also present in the 2.1.281 and 2.1.282 binaries). Summary: CLAUDE_CODE_WORKFLOW_PROMPT_PROVENANCE is read through an accessor that exposes no keys, so it can never take effect in these builds. The GrowthBook gate is the only switch.

Where it is read (2.1.283 bundle, minified names as shipped):

function ssr(){let e=Nn.CLAUDE_CODE_WORKFLOW_PROMPT_PROVENANCE;if(e!==void 0)return e;return x("tengu_bubbly_harbor",!0)}

Nn is imported from the env-accessor chunk, where it is constructed as:

function Dhn(o,t){let _=Object.create(t);for(let[E,r]of Object.entries(o)){ /* defines a process.env getter per key of o */ } ... return _}
var a=Dhn(xU,p),NU={},Nn=Dhn(NU,null)

NU is an empty object and the prototype is null, so Nn has no readable properties. Nn.CLAUDE_CODE_WORKFLOW_PROMPT_PROVENANCE is always undefined, and the function always falls through to x("tengu_bubbly_harbor",!0) (default true; cached as true under cachedGrowthBookFeatures in ~/.claude.json). The typed accessor a does not carry the key either. Separately, the callers use the return value as a plain truthy/falsy (Be?isr(...):null, !Be?U:...), so even a wired accessor would ignore 0 or false; only an empty string could disable it.

Test. Set "env": {"CLAUDE_CODE_WORKFLOW_PROMPT_PROVENANCE": ""} in .claude/settings.json. In the same session, without a restart, the empty value was present in the Bash tool's child environment. Then launched a one-agent Workflow whose only task was to quote the first message it received. The agent's transcript opened with both frames unchanged: [Workflow harness — user request] relaying my last typed line, followed by [Workflow harness — computed task] ... carries no user authority .... So the variable has no effect with an empty value, and by the code above it can have none with any value.

Relay behaviour observed, for anyone hitting this: the relayed text is the newest user-driven record, and only when it is a plain human record under 4,000 characters and the launch is not from a child session. After a ! <command> bash-input line, workflows receive only the computed-task frame. A message queued mid-turn becomes the relayed request. When the last typed line is not a task statement (e.g. a session-open line), agents treat the script's task text as unauthorized and decline it, since the frame says the relayed line is the only user voice.

Ask: either wire the variable to the typed env accessor and document the accepted values, or expose an equivalent settings key, or document that the gate is server-side only.