/fork <prompt> leaks the forked task into the parent session — the parent executes it too (risking duplicate side effects)

Summary

When I run /fork <prompt> to hand a task to a background forked agent, the forked prompt is also delivered to the parent session as if it were a parent-directed instruction. The parent assistant then starts executing the same task the fork is running — including outward, side-effecting actions. The forked agent's task-notifications and final result also surface in the parent transcript.

The whole point of /fork <prompt> is isolation: the fork should own the task and the parent should continue undisturbed. Instead the work runs twice, in parallel, in two sessions that share the same git worktree.

This has now happened in two separate sessions, so it appears reproducible rather than a one-off.

Expected behavior

/fork <prompt> spawns an isolated forked agent that runs <prompt>. The parent session should either (a) not receive the forked prompt as an actionable instruction at all, or (b) receive only a "a fork was spawned to handle X" notice — never begin executing <prompt> itself.

Actual behavior

1. The /fork command and its full <command-args> prompt are surfaced in the parent session's input.
2. The parent assistant treats those args as its own task and begins working it, in parallel with the fork.
3. The fork's background task-notifications and its final result message are delivered into the parent transcript.
4. Net effect: the task executes in both sessions, which share the same working tree.

Why this is more than cosmetic

The forked task in my case was: "check if an upstream GitHub issue exists; if not, create one; then create a scheduled routine." Both agents independently:

• searched the upstream repo's issues,
• read its CONTRIBUTING guide,
• headed toward filing a public GitHub issue and creating a scheduled cloud routine.

The parent only avoided filing a duplicate public issue by luck — "check for an existing issue first" was part of the task, and the parent happened to find the one the fork had just created (authored by the same account seconds earlier). For a task phrased as "open a PR", "send the Slack message", or "create the routine" with no pre-existence check, both agents would have performed the outward action, producing duplicates. Because forks share the parent's git worktree and can commit/push, parallel duplicate execution can also race on the working tree.

Secondary costs: wasted tokens (the parent re-did ~the fork's research) and a polluted parent transcript.

Reproduction

1. In an interactive session, run /fork <a prompt that includes a side-effecting action, e.g. "create a GitHub issue about X">.
2. Observe the forked agent spawn (e.g. ⑂ forked <name> (<id>)).
3. Observe the parent session receive the forked prompt and begin executing it (tool calls working the same task).
4. Observe the fork's task-completion notification / result also appear in the parent transcript.

Evidence from the real session

• /fork was issued with a multi-step task in <command-args>; parent stdout showed ⑂ forked is-there-already (1fd4).
• The parent assistant then ran upstream-repo issue searches and read the third-party CONTRIBUTING file — i.e., executing the forked task — before discovering the fork had already created the issue (#831, authored by the same account ~seconds earlier).
• A background task-notification for the forked agent (ais-there-already-…) and its full final result were delivered into the parent transcript.

Impact

• Duplicate outward/irreversible actions (public issues, PRs, messages) when the forked task is side-effecting.
• Worktree races — forks share the parent's checkout and can commit/push.
• Wasted tokens and transcript confusion.

Environment

• Claude Code: 2.1.206
• OS: macOS 26.5.2 (Darwin 25.5.0)
• Session type: interactive CLI, with a git worktree checkout; forked agent ran as a background agent (separate task id, own token/tool-use accounting).

Suggested direction

Treat a /fork <prompt> as "route <prompt> to the fork only." The parent should not be handed the forked prompt as an actionable instruction, and forked-agent notifications/results should stay in the fork unless the user explicitly resumes/merges it.