[BUG] Background session: EnterWorktree always fails (`git worktree list` exit 1) while the same command succeeds in any shell — isolation guard deadlocks all edits

Environment

• Claude Code: 2.1.x (reproduced both before and after an upgrade on 2026-07-16; exact version available in the private /feedback report accompanying this issue)
• Platform: Arch Linux (kernel 7.1.3-zen1-3-zen), shell: fish, git: system /usr/bin/git (no wrappers/aliases; which -a git shows only /usr/bin/git)
• Session type: background job (claude background session) in a git repo; several concurrent background sessions on the same repo

Bug description

In one background session, the EnterWorktree tool fails 100% deterministically, in both of its modes:

1. Create mode ({name: "repo-dep-single-txn"}) returns Failed to create worktree: — with an empty error detail after the colon.
2. Enter mode ({path: "<repo>/.claude/worktrees/repo-dep-single-txn"}, pointing at a healthy, registered worktree created manually with git worktree add) returns:

``
git -C /home/nb/src/aurox worktree list failed: exit 1
``

The command the tool claims fails succeeds in every environment constructible from the same session's Bash tool:

• git -C /home/nb/src/aurox worktree list → exit 0
• env -i /usr/bin/git -C /home/nb/src/aurox worktree list → exit 0 (so not env/config dependent)
• fish -c 'git -C … worktree list' → exit 0
• git worktree list --porcelain → all registrations healthy, no prunable/broken entries
• config is benign: safe.directory=*, no fsmonitor, no core.sshCommand oddities

Key observations

• Persists across a full harness restart and a version upgrade (same two error strings before and after).
• Failure is session-specific, not repo-specific: while this session's EnterWorktree was failing, a different concurrent background session successfully created a worktree in the same repository (it appeared in git worktree list between my attempts).
• The tool's internal git subprocess apparently exits 1 with no captured stderr — the empty Failed to create worktree: message suggests stderr is swallowed, making this undiagnosable from inside the session.

Consequence: edit deadlock

Because this is a background session, the isolation guard rejects every Edit/Write with "Call EnterWorktree first…" — but EnterWorktree can never succeed, so the session is permanently unable to edit files. The guard's suggested escape hatch ("worktree": {"bgIsolation": "none"} in .claude/settings.json) has to be applied by the user, since the session can't write the settings file through blocked tools either.

This is the same deadlock shape as #73824 (and the discoverability complaint in #64640), but with a distinct root cause: there, EnterWorktree is structurally unable to resolve a path; here, its internal git worktree list invocation fails in an environment where that command demonstrably works.

Related (checked, not duplicates): #73824, #64635, #64640, #65616 (isolation-guard deadlock variants); #62946 (cwd-override refusal, different error); #67196 (EnterWorktree leaves core.hooksPath in shared .git/config — its fingerprint is present in this repo from an earlier session, ruled out as the cause since worktree list ignores hooks); #47266 / #34645 (closed config-lock races — deterministic across restart, so not a race).

Expected behavior

EnterWorktree enters/creates the worktree — or at minimum surfaces the real stderr of its failing git invocation. A background session should never be able to reach a state where isolation is mandatory but unachievable.

Steps to reproduce (as far as known)

1. Start several background sessions against the same git repository.
2. In one of them, invoke EnterWorktree (create mode) — observe Failed to create worktree: with empty detail.
3. Create the worktree manually (git worktree add .claude/worktrees/<name> -b <name>), then invoke EnterWorktree with path — observe the git worktree list failed: exit 1 error while the same command exits 0 from the session's own Bash tool.
4. Any Edit/Write in the session is now permanently blocked by the isolation guard.

A private /feedback report with the full session transcript accompanies this issue.