/branch (/fork) always fails with 'No conversation to branch' in background (daemon-backed thin-client) sessions

Status Fixed / completed

Reported on v2.1.143

Maintainer reply ✓ Yes — claude[bot]

Activity 3 comments · opened May 17, 2026 · closed May 19, 2026

💡 Likely answer: A maintainer (claude[bot], contributor) responded on this thread — see the highlighted reply below.

Bug

/branch (and its alias /fork) always fails with Failed to branch conversation: No conversation to branch when invoked against a background session (daemon-backed thin-client REPL — e.g., the bg/Agents view).

The session JSONL exists on disk under the expected project directory, so the conversation data is there — it just isn't reachable from /branch in thin-client mode.

Environment

Claude Code 2.1.143
macOS 26.4.1 (arm64)

Repro

Start a background session (Agents View / bg job).
In the thin-client view of that session, type /branch (or /fork).
→ Failed to branch conversation: No conversation to branch

(Same /branch works fine from a normal local REPL session in the same project.)

Evidence the conversation is on disk

State of the bg session I tested:

~/.claude/jobs/<short>/state.json:
  "sessionId": "923d0a88-3740-4f2c-beb8-76dc32051900",
  "resumeSessionId": "923d0a88-3740-4f2c-beb8-76dc32051900",
  "bridgeSessionId": "cse_01UWkiSRXQbWGRsn8o9wJefR",
  "backend": "daemon",
  "cwd": "/Users/me/projects/foo",
  "originCwd": "/Users/me/projects/foo",

The corresponding jsonl is on disk and accumulating messages normally:

~/.claude/projects/-Users-me-projects-foo/923d0a88-3740-4f2c-beb8-76dc32051900.jsonl  (25 lines, growing)

So this is not a missing-conversation issue — /branch is failing despite a perfectly valid session file at the expected location.

Observed behavior

The failure is 100% reproducible in any bg/thin-client session, regardless of message count, regardless of project (tested across multiple repos).
The same command in a normal foreground REPL on the same project succeeds.
The cwd of the bg session matches its originCwd, so this is not the EnterWorktree-induced cwd-change case from #48254.
/btw <question> followed by the f (fork) hotkey does work from the same bg session — suggesting the fork machinery itself isn't broken, only /branch's entry point isn't routed correctly for thin-client mode.

Related (not duplicates)

#48254 — same error string, but root cause is cwd-change via EnterWorktree resolving the project dir to a different folder. Different mechanism; my session's cwd is stable and matches originCwd, and the error reproduces without ever entering a worktree.
#45179 / #48110 — submodule/bare-repo worktree path-resolution issues for /resume, not /branch in thin-client mode.

Suggested fix

Route /branch through the daemon when invoked from a thin-client REPL, the same way /btw's fork hotkey works in bg sessions today. Whatever predicate distinguishes thin-client/bg from local REPL for /btw should gate /branch's dispatch as well.

View original on GitHub ↗

3 Comments

kcarriedo · 5 months ago

Your /btw + f vs /branch asymmetry is the right diagnostic — and I think it pins the bug more precisely than the issue title suggests. It isn't "/branch doesn't work in bg sessions" — it's "/branch's dispatcher resolves the conversation against the local-REPL conversation registry, not against the daemon's registry, in thin-client mode."

A few observations from the same surface that may help whoever's triaging this:

The thin-client /btw fork path almost certainly proxies through the daemon's session resolver — which is why it succeeds against a session whose JSONL lives at ~/.claude/projects/... but whose live state is owned by the daemon (backend: "daemon" in the state.json you pasted). /branch doesn't appear to use that proxy. Locating the predicate that decides "is this session daemon-owned?" inside /btw's fork code path is probably the right starting point — its f hotkey is the version of /branch that already works.

#48254 is genuinely a different mechanism — your cwd == originCwd rules out the EnterWorktree path. Worth keeping the two issues separate; the fixes are likely in different files even though the error string is identical. The error message itself is the leak: "No conversation to branch" really means "no conversation that this dispatcher can see" — a more informative error (e.g., "Conversation owned by daemon; thin-client cannot branch directly") would have saved you the disk archaeology.

The class of bug is going to keep appearing as the bg/Agents-View surface grows — anything that takes a slash command, looks up the current session by some local-process notion of "current," and then operates on it will fail the same way until thin-client dispatch is routed uniformly. /resume, /clear, /compact, /export are all worth audit-grepping for the same pattern. (The /btw family appears to already be fine because it was bg-aware from day one.)

The thin-client / daemon split is great architecture; the asymmetry will resolve as more of the slash-command surface gets daemon-aware. Thanks for the deeply-instrumented repro — state.json + JSONL line count + originCwd rule-out is exactly the shape that makes this triagable.

claude[bot] contributor · 4 months ago

This issue was fixed as of version 2.1.144.

github-actions[bot] · 3 months ago

This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.