[Bug] Fork on completed /btw response re-submits original prompt instead of continuing session

Authorship note: Claude wrote the below comment under my guidance. I did actually perform the described repro myself, it's not just a Claude hypothetical.

Edit: I changed "I / my" to the "the user / the" so it's more clear that Claude wrote it.

---

Additional context: root cause from session logs, plus a clean-room repro (Claude Code v2.1.233, macOS).

The user's (Daniel's) original report said pressing f "re-submits the original message." After examining the session logs (the main session's JSONL and the fork's transcript under subagents/) and reproducing in a fresh session, the picture is more specific. There are two bugs that chain into an automatic failure, plus two UX problems.

Summary: pressing f on a completed /btw response (1) spawns the fork as a one-shot worker that re-executes the already-answered question and exits, and (2) writes the /btw question into the main session's history, where the main assistant picks it up and responds. The two combine: the worker's completion notification triggers the main session seconds after the f press, so the leak happens with no further user action.

Minimal repro

1. Start a fresh session and send one ordinary message, so there is some context.
2. /btw <any question>. The overlay answers normally (isolation is still intact at this point).
3. In the response viewer, press f to fork.
4. Touch nothing and wait about 10 seconds.

Observed: the fork runs on its own and terminates (Bug 1). Its completion notification reaches the main session, which now has the /btw question and the fork's answer in context and responds to them (Bug 2).

To verify directly, ask the main assistant "do you see the /btw message in your context?". In the main session's JSONL, the /btw command turn appears as "subtype":"local_command" records timestamped at the f press, not at the /btw submission.

Bug 1: f creates the fork as a one-shot worker, not a continuable session

The fork's transcript shows the documented part working first: the /btw question and the overlay answer are copied in as real transcript turns (their timestamps are identical, milliseconds after fork creation, so this is a copy rather than a live generation). Immediately after, a <fork-boilerplate> turn is appended:

"You are a worker fork. The transcript above is the parent's history — inherited reference, not your situation. You are NOT a continuation of that agent. Execute ONE directive, then stop."

…with the already-answered question as its directive. The fork obeys: it re-answers the question on its own (in the repro it ran git log via Bash to re-answer what the overlay had already answered) and then stops, per the boilerplate's "report once and stop." Total lifetime in the repro: about 8 seconds. The continuable session the docs describe never exists, and by the time the user navigates to the agent, it has finished.

(In the user's original session, they did get a conversation with the fork, but only because they happened to interrupt its self-run with Escape and then message it, which resumed it.)

The docs (interactive-mode.md, response-viewer keybindings) describe f as forking into a new session that inherits the Q&A "so you can continue with full tool access."

Bug 2: f leaks the /btw question into the main session's history

The /btw submission itself writes nothing about the question to the main session's log, so the documented isolation holds at that point. The f press is what breaks it: it appends the /btw command turn and the fork stdout to the main session's log as "subtype":"local_command" records with isMeta: false. That is the ordinary, model-visible record type used for slash-command turns.

Those records sit pending until the next model invocation in the main session, whatever triggers it:

• In the repro, the trigger was the fork's own completion notification, about 7 seconds after the f press, with no further user action.
• In the original session, the trigger was a "stopped by user" notification (I had interrupted the fork's self-run with Escape) about 42 seconds after the f press.

At that invocation, the main assistant receives the question as a normal command turn and responds. (Notably, the records arrive without the <local-command-caveat> wrapper that accompanies local-command records delivered alongside a regular user message, so nothing tells the assistant to ignore them.) In the original session it produced a full second answer, different from the overlay's and generated with tool access (it wrote files). In the repro it relayed the fork's answer. Either way, the question and the fork's answer (carried in the task notification) both end up in the main session's history.

The documented contract (interactive-mode.md, "Side questions with /btw"): "The question and answer never enter the conversation history."

UX problems

• In the repro, pressing f returned the user to the main session instead of switching into the fork, which was only reachable through the background-agents UI (down arrow). By then, it had already finished per Bug 1. The forked session wasn't usable at all.
• Every stop or finish of the forked session emits a task notification into the main session, waking the main assistant each time (about 5 wakes during a few minutes of talking to the original fork). This defeats the isolation the feature exists for.

Suggested fixes

• Bug 1: on f from a completed exchange, seed the fork with the Q&A as history and give the user the prompt. No worker directive, no self-started run.
• Bug 2: don't log the /btw command turn to the main session on f (or flag it so context assembly excludes it), and suppress the fork's lifecycle notifications in the main session, or at least strip the /btw content from them.

Evidence available on request: record-type and timestamp skeletons from both sessions' JSONLs showing the local_command records written at the f press, the copied Q&A pair, the <fork-boilerplate> directive, and the fork's self-started run.

btw, I'll be watching this thread myself, so if further details or info would be useful, let me know. I hope the above breakdown is helpful and clear.

Edit: One more note. I don't fully understand what happened in the original session which caused the forked agent to receive the <message> from /btw <message> as a second message, right at fork time. That was why I hit "escape" on the forked agent, which then caused it to not be auto-finished, and thus I could continue interacting with it. This issue was, in fact, produced by the /feedback -> github issue flow in that original forked agent.

Confirmed / reproduced on 2.1.234 (Linux): after a /btw question has been answered in the overlay, pressing f does not open a continuable forked session. It spawns a one-shot background fork (⑂ forked … (xxxx)) whose context is the parent transcript + the /btw question and answer, followed by the same question again as its directive, so it immediately re-answers it (an extra model request) and finishes within seconds. You stay in the original session, and on its next model call that session's context now contains the /btw command turn, the fork's output line and the fork's completion notification, and the assistant responds to them without any user action — matching both parts of the follow-up analysis above.

This differs from the documented behaviour of f ("Fork into a new session… so you can continue with full tool access") and of /btw ("The question and answer never enter the conversation history"): https://code.claude.com/docs/en/interactive-mode

🤖 Generated with Claude Code

---
_Generated by Claude Code_