[BUG] Worktree-isolated agents report confident false results, because nothing discloses that the worktree lacks the user's uncommitted work

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report
• [x] I am using the latest version of Claude Code

What's Wrong?

An agent that isolates into a git worktree receives no indication of what the worktree does
not contain. That covers a background session calling EnterWorktree and a subagent spawned
with isolation: "worktree" — both shown below — and, per the worktrees docs, every session
in the desktop app, which gets its own worktree automatically.

A worktree carries committed, tracked content only. It does not have the user's uncommitted
changes, and under the default worktree.baseRef: "fresh" it does not have local commits
either, since it branches from origin/<default>. With a modified tracked file live in the
checkout, EnterWorktree returns this, in full:

Created worktree at /…/.claude/worktrees/<name> on branch worktree-<name>. The session is now working in the worktree. Use ExitWorktree to leave mid-session, or exit the session to be prompted.

Path and branch. Never the main checkout's uncommitted files, never which base ref was used,
never how far behind that base is. The agent then reasons about a tree the user cannot see,
and reports its conclusions as facts about "this repository."

Git never overwrites the uncommitted work. The report is what causes it to be discarded — a
user who dispatched an agent in order not to watch it acts on "there is nothing to do," or
merges a PR built on a base that omits their changes.

This is correct behavior for independent work starting from a clean base. It fails when the
task concerns the working state: "fix the bug I just wrote", "review my working diff",
"remove all references to X".

What Should Happen?

The isolation result should state what the worktree does not contain — e.g. "the main
checkout has N uncommitted files and M local commits not present in this worktree."

That alone prevents the failure: the agent can decline to isolate, qualify its answer, or
tell the user it is working from a different base.

A reused worktree does get an extra note warning that it may carry an earlier session's
commits — so this is an inconsistency in what gets surfaced, not a new class of message.

worktree.bgIsolation: "none" is not this fix. It removes isolation altogether, trading
collision protection for truthfulness, rather than disclosing what an isolated tree lacks —
and it applies only to background sessions, leaving subagents spawned with
isolation: "worktree", claude --worktree, and desktop-app sessions unaffected.

Steps to Reproduce

Verified end to end on 2.1.220.

1. On a clean checkout of main, add an uncommitted edit to a tracked file — here,

I like aardvarks. in README.md. Confirm it exists only in the working tree:

``console
$ git grep -i aardvark
README.md:I like aardvarks.
$ git grep -i aardvark HEAD # no matches
$ git grep -i aardvark origin/main # no matches
``

1. Dispatch an agent with worktree isolation, with the task phrased exactly as a user would

and no hint about worktrees: "Remove all references to aardvarks from this
repository."

1. The agent isolates and reports:

> No changes were needed — there are zero references to aardvarks in this repository.
>
> What I checked (worktree at .claude/worktrees/agent-<id>, 2,092 tracked files):
> - Case-insensitive content grep for aardvark across the whole tree — no matches
> - git grep -in "aardvark" over tracked files — no matches (exit 1)
> - Filename search (git ls-files and find -iname "*aardvark*") — no matches
> - Broader stem search for aardv (to catch typos/truncations) — no matches
> - Sanity check confirming grep was actually working against a populated tree:
> otherly matched 271 files

1. The user's working tree still contains the aardvark reference. The statement "there are

zero references to aardvarks in this repository" is false for the repository the user is
looking at.

The agent did nothing wrong. It ran five independent searches and an explicit sanity check
against a false negative, and produced a confident false statement anyway, because its
ground truth was a tree the user never saw. Agent diligence cannot correct this; only
disclosure at isolation time can.

Calling EnterWorktree directly, with the same uncommitted README.md edit live, returned
exactly the message quoted above and nothing more. The resulting worktree sat at the same
commit as the main checkout and contained no aardvark reference, while the checkout it was
created from did.

Is this a regression?

No, this never worked

Uncommitted changes have never been carried into a worktree — that is plain git. Worth
noting only that the 2.1.133 changelog describes the worktree.baseRef default fresh as
changing "EnterWorktree's base back to origin/<default> (it has been local HEAD since
2.1.128)", which widened the gap by dropping local commits too.

Claude Code Version

2.1.220 (Claude Code)

Platform

Anthropic API

Related

All closed and locked; the lock bot directs filing a new issue referencing them.

• #12586 — closest prior report: Desktop creates a worktree silently, excludes

uncommitted changes, and asks for a notification. The reporter closed it as a duplicate of
#12513, which is about disabling automatic worktree creation — so the notification ask
itself was absorbed into a different question and never addressed.

• #58433, #58435 — background-session isolation gate and opt-out. #58433 closed as

completed 2026-05-14; worktree.bgIsolation: "none" shipped in 2.1.143 on 2026-05-15.
Those concern whether isolation happens at all, not what it discloses.

• #50850 — subagent worktree from a stale base, no warning surfaced. Same silence,

different entry point.