[BUG] EnterWorktree mid-conversation strands history — next message starts an empty session

Open 💬 0 comments Opened Jul 10, 2026 by crentier

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?

EnterWorktree mid-conversation strands history — next message starts an empty session

Environment: Claude Code 2.1.175, desktop app (entrypoint: claude-desktop), macOS 26.5.1

Summary

When a conversation calls EnterWorktree mid-session, its transcript is
physically moved from the original project directory under
~/.claude/projects/ to the worktree's project directory, with no stub or
forwarding pointer left behind. After the turn completes, the next user
message to the same UI thread does not resume the relocated transcript —
the app mints a brand-new session file back in the original project
directory (parentUuid: null, no summary, no reference to the prior
transcript). The thread keeps its custom title but loses all scrollback,
and the assistant continues with zero context. The worktree itself still
exists throughout — nothing was cleaned up; this is purely the
relocate-then-resume sequence breaking the pointer chain.

Timeline (from the transcript records)

  1. Jul 7 19:27 UTC — conversation starts in the main repo

(~/src/<repo>); transcript at
~/.claude/projects/-…-<repo>/65aad654-….jsonl.

  1. Jul 8 22:48 UTC — assistant calls EnterWorktree {name: "<wt-name>"}

to prepare a branch/PR. The transcript file is relocated to
~/.claude/projects/-…-<repo>--claude-worktrees-<wt-name>/65aad654-….jsonl
and accumulates relocated records:
{"relocatedCwd": "…/<repo>/.claude/worktrees/<wt-name>"}.
No file or stub remains at the original path.

  1. Jul 8 22:54 UTC — PR created; last records in the relocated file:

custom-title, ai-title, relocated, mode, worktree-state,
pr-link. No ExitWorktree call; session goes idle.

  1. Jul 8 23:31 UTC — user sends a short follow-up ("Cool ty!") to the

same UI thread. First records of a new file
(-…-<repo>/14b47c55-….jsonl, back in the main project dir, new
session UUID):

``
{"type":"queue-operation","operation":"enqueue","content":"Cool ty!", …}
{"type":"queue-operation","operation":"dequeue", …}
{"parentUuid":null, "type":"user", …} ← no link to prior transcript
``

The custom-title record carries over (thread keeps its user-set name);
the history does not.

Observed

  • UI thread shows only the post-break messages; user assumed the history

was lost.

  • The orphaned segment is not discoverable: the thread is the current

session, so it never appears in session lists, and the old file lives in
a project directory keyed to the worktree path.

  • Assistant answers with no memory of the earlier conversation, including

the branch and PR it had itself created in that same thread minutes
earlier.

Control case (same app instance, same minute)

A second conversation in the same repo did the identical workflow that
afternoon — created a worktree, committed, opened a PR — but via plain
git worktree add in Bash rather than the EnterWorktree tool. Its
transcript has zero relocated records and never left the main project
directory. A follow-up message sent to it at 23:31 UTC (the same minute as
the broken thread's) appended normally and the thread continued for
another 18 minutes without issue.

So app restarts, session renames, archiving, and idle time are all ruled
out as ingredients: two threads differing only in EnterWorktree-vs-manual
worktree creation diverged exactly on whether the transcript had been
relocated.

Expected

A mid-conversation EnterWorktree should not be able to sever the thread:
either leave a forwarding pointer at the original transcript path, relocate
the transcript back on idle/exit, or have resume follow the relocated
records. At minimum the UI should indicate that earlier history exists but
is detached.

Repro sketch

  1. Start a conversation in a repo (desktop app).
  2. Have the assistant call EnterWorktree mid-session and finish the turn

(no ExitWorktree).

  1. Send another message to the same thread.
  2. New session file is created in the original project dir with

parentUuid: null; scrollback and context are gone. The worktree and
the relocated transcript still exist untouched.

Workaround (verified)

Manually splicing the orphaned segment into the successor file restores both
scrollback and resume context: concatenate the old file's records (rewriting
their sessionId to the new file's, dropping stale worktree-state/mode
records) ahead of the new file's records, and re-parent the new segment's
root user message (parentUuid: null → last uuid of the old segment).
Merged file parses and renders fine.

What Should Happen?

Expected

A mid-conversation EnterWorktree should not be able to sever the thread:
either leave a forwarding pointer at the original transcript path, relocate
the transcript back on idle/exit, or have resume follow the relocated
records. At minimum the UI should indicate that earlier history exists but
is detached.

Error Messages/Logs

Steps to Reproduce

Repro sketch

  1. Start a conversation in a repo (desktop app).
  2. Have the assistant call EnterWorktree mid-session and finish the turn

(no ExitWorktree).

  1. Send another message to the same thread.
  2. New session file is created in the original project dir with

parentUuid: null; scrollback and context are gone. The worktree and
the relocated transcript still exist untouched.

Claude Model

Other

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.175

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

Full report generated by Claude.

View original on GitHub ↗