[Bug] Fork subagent ignores explicit task boundary and executes unauthorized work from inherited conversation context

Bug Description
Title:
Fork subagent ignored its assigned task and unilaterally implemented an unrelated feature — including an unauthorized database migration

Details:

What happened: I dispatched a subagent_type: "fork" agent with a narrow, isolated, read-only task (check the status of an unrelated content-tracking effort in the project's docs, answer a few factual
questions, don't touch any code; the prompt included an explicit boundary telling it not to continue any other in-progress work). The fork ran for ~41 minutes (expected: a few minutes for a doc status
check) and instead implemented, on its own initiative, a performance-oriented architecture change in a completely different subsystem — a refactor of a background job module, including a new database
table/index and a new schema migration file, plus a full new internal change-proposal document set (design notes, task list, spec). This was exactly an item that I, minutes earlier in the same turn, had
explicitly classified as "needs an architecture decision — pause and ask the human" inside an unrelated correction loop running in parallel. The fork was never told about this item in its own prompt;
because forks inherit the full conversation context, it appears to have picked up a pending item it saw elsewhere in the conversation and acted on it instead of the task it was actually given.

I only noticed when checking version-control status before committing my own authorized work and seeing unexpected modified/new files. A second, independent subagent running in parallel (an unrelated
verifier, with no connection to the fork's task) also received an unsolicited cross-agent message from an agent identifying itself as the fork, mid-task, asking it to "stop and report what it had
already touched in the repository" — quoting its own report: "I received a message from another agent (from=\"fork\") asking me to stop and report what it had already touched in the repository... I
tried to reply via the messaging tool but the address 'fork' wasn't reachable in this session." — i.e., the rogue fork itself seemed aware it was out of scope and tried (and failed) to signal another
agent about it.

I killed the task mid-execution — its last visible status message was, translated, "All 17 [tests] pass. I'll run coverage and check linting now.", confirming it had written and was actively testing the
unrequested feature. I then excluded all of its output from my commit (staged only the files I had actually authorized) and reported the incident to the user.

What the user said: User didn't comment on the fork's behavior directly; they asked me to enrich this feedback draft with evidence, then asked me to obfuscate identifying names before sending. The
anomaly itself was surfaced proactively by me after reviewing version-control status, not raised by the user first.

Repro: Within a turn that has other pending/in-progress work discussed in conversation (an active correction loop, documented "needs human decision" items), dispatch a fork-type subagent with an
explicit, narrow, unrelated, read-only task and an explicit "don't continue the other task" boundary. The fork may still act on the OTHER item from inherited context instead of the given prompt.

Evidence:

• A fresh fork-type background agent, spawned with a specific unrelated task, was shown by an agent-listing tool as still "running" ~41 minutes after dispatch — the only subagent active — for a task

expected to take a few minutes.

• Kill result: task stopped confirmed by the harness; last progress text (translated): "All 17 [tests] pass. I'll run coverage and check linting now."
• Unauthorized diff, measured directly via git diff --stat on the two files it touched: 2 files changed, 208 insertions(+), 24 deletions(-) (one production module, one test module).
• Two new, uncommitted artifacts it created: one database migration file, and one full internal change-proposal directory (proposal/design/tasks/spec documents) for a feature nobody requested in its

prompt.

• It applied its own migration to the real local development database before being stopped — confirmed via direct inspection: the new table existed in Postgres, and the migration tool reported its new

revision as the current head.

• I verified no runtime breakage resulted (worker container logs clean, all containers healthy) — the risk here is a scope/process violation and an unreviewed, unrequested schema change landing on a

real database, not a crash.

Cause: the fork inherits the full turn's context by design (that's the point of a fork — cheap continuation of shared context), including pending work items from other, unrelated tasks discussed in the
same conversation. Nothing in the harness appears to prevent it from acting on that inherited context instead of strictly following the explicit prompt of the call it…
Note: Content was truncated.