[BUG] /btw → f creates a fork subagent and re-executes the already-answered question
Preflight Checklist
- [x] I have searched existing issues and this hasn't been reported yet
- [x] This is a single bug report (please file separate reports for different bugs)
- [x] I am using the latest version of Claude Code
What's Wrong?
Pressing f after a completed /btw answer appears to create a forked subagent/task instead of a standalone interactive fork.
The already-answered /btw question is executed again, producing a second unnecessary model response. The fork then terminates autonomously and returns its result to the parent session, where the parent may process or summarize it.
A direct /fork works correctly on the same setup, so the issue appears specific to the /btw → f flow.
What Should Happen?
After /btw finishes answering a question and f is pressed:
- A standalone interactive fork should be created.
- The fork should inherit the parent transcript.
- The completed
/btwquestion and its already-generated answer should already be present in the fork's transcript. - The fork should wait for the user's next prompt.
- The
/btwquestion should not be executed again. - The fork should not autonomously terminate or return a result to the parent session.
This should behave similarly to a direct /fork, except that the completed /btw exchange is also included in the new session.
Error Messages/Logs
There is no explicit error message.
The resulting fork has been observed with metadata similar to:
{"agentType":"fork","isFork":true,"spawnDepth":1}
It also appears under the parent session's `subagents/` data rather than behaving like the standalone session created by a direct `/fork`.
The observable sequence is:
/btw question
→ /btw answer
→ press f
→ same question is executed again
→ second answer is generated
→ fork terminates
→ result is returned to the parentSteps to Reproduce
- Start a fresh Claude Code session.
- Enter some initial context.
- Run a simple
/btwquestion. - Wait until
/btwhas completely answered it. - Press
f. - Do not enter any additional prompt.
- Observe that the new fork immediately executes the already-answered
/btwquestion again. - Observe that the fork then terminates and returns its result to the parent session.
Claude Model
Opus
Is this a regression?
I don't know
Last Working Version
_No response_
Claude Code Version
2.1.228 (Claude Code)
Platform
Anthropic API
Operating System
Windows
Terminal/Shell
WSL (Windows Subsystem for Linux)
Additional Information
Environment:
- Claude Code:
2.1.228 - Claude daemon:
2.1.228 - Agent View: enabled and working
claude doctor: no issues reported
A direct /fork behaves correctly on the same installation and environment.
This makes the problem appear isolated to the /btw → f promotion path rather than to Agent View, the daemon, or standalone fork functionality in general.
The bug also causes unnecessary model usage because the /btw question is answered once before the fork and then generated again inside the fork.
3 Comments
I found a few related reports that may help narrow this down.
The expected behavior is clear from the Claude Code docs: after a /btw, pressing f should create a new independent session containing the parent conversation plus the /btw question/answer.
What I observe instead is effectively:
parent session
→ /btw question + answer
→ press f
→ "fork" subagent is spawned
→ the already-answered /btw question is executed again
→ its result is returned to the parent session
→ the forked agent exits
So it looks like the /btw → f path is going through a subagent-style fork rather than the normal session-fork flow.
A few possibly related issues:
#83971 — session/background transition re-executes an already-answered prompt and loses expected context
#55273 — /btw fork/branch behavior leaves the session in the wrong branch/state
#45460 / #47557 / #63605 — previous reports of /btw questions being executed twice after session/UI state changes
#70373 / #85004 — other recent problems around session forks, backgrounding, resume, and parent/child session state
One detail that may be relevant: in v2.1.212, /fork was changed from launching an in-session subagent to creating a separate background session; the old behavior moved to /subtask.
Given that transition, I wonder whether /btw → f is still accidentally hitting some legacy/subagent fork path.
In my reproduction, seeing things such as agentType: "fork", isFork: true, spawnDepth: 1, and output under subagents/ seems consistent with that hypothesis.
I don't know if that is the actual root cause, but hopefully it gives maintainers a narrower area to investigate.
Reproduced on 2.1.233 (Linux, tmux): asked one question, ran
/btw what is 2+2?, got the answer, pressedf. The session printed⑂ forked what-is-22, a background agent re-answered the already-answered question, finished on its own in ~1s, and reported "2 + 2 = 4" back into the parent conversation. No standalone interactive fork opened — exactly what you describe.This is the currently shipped behavior rather than a recent break: since around v2.1.161,
fhands the question and answer to a background fork that runs with full tool access and reports back while your session stays live (it previously switched you into a new session). Because the fork's instruction is the original question, it visibly answers it again — redundant-looking for a question that needed no tools.That said, we agree this is confusing: the docs for
/btwstill describe the old "fork into a new session, original preserved under /resume" behavior, and/forkbehaves differently, so thefhint sets the wrong expectation.We're looking at updating the docs to match what ships, and at making the fork continue from the existing answer instead of re-running the question. Keeping this open to track that.
🤖 Generated with Claude Code
Thank you, it would be much better if the /btw fork was an actual fork rather than a sub agent that is not resume-able.
On the other side, the ability for the main session to monitor the fork conversation is interesting sometimes. So maybe we could have the choice between the two?