Background session edit-gate misfires when cwd is already a git worktree (catch-22 with EnterWorktree)

Summary

In a background Claude Code session whose cwd is already a git worktree, Edit/Write/Bash file mutations are blocked by the harness with:

This background session hasn't isolated its changes yet. Call EnterWorktree first so edits land in a worktree instead of the shared checkout, then retry this edit using the worktree path.

The "isolated" check appears to only treat paths under .claude/worktrees/ as isolated, so any other worktree layout — e.g. a project-local .worktrees/<branch>/ created via standard git worktree add — is treated as "the user's working copy" even though it is, in fact, an isolated worktree.

The catch-22

The error message instructs the agent to call EnterWorktree first. But EnterWorktree with path pointing at the current cwd refuses with:

Cannot enter worktree: <path> is the current working directory.

So:

• The Edit gate says: "you're not in an isolated worktree — call EnterWorktree first."
• EnterWorktree says: "you're already in this worktree — can't enter it."

The agent is stuck. The only escape hatches are:

1. Have the user change the parent shell's cwd to somewhere else and re-enter — which worked for me, but is a confusing dance and depends on the user knowing this.
2. Call EnterWorktree to spawn a new nested worktree under .claude/worktrees/, edit there, then push to the same branch (or hand the user a patch). This duplicates the worktree directory and creates branch-sync friction.
3. Ask the user to apply the change manually.

None of these are what you'd want.

Reproduction

1. From any repo, create a worktree outside .claude/worktrees/, e.g. git worktree add .worktrees/feature -b milan/feature.
2. cd into it.
3. Start a Claude Code background session from that cwd (e.g. /bg).
4. Have the agent attempt any Edit/Write/Bash file mutation.

Expected: edit succeeds — cwd is already an isolated worktree per git worktree list.
Actual: edit blocked with the message above. Calling EnterWorktree with the cwd path also fails.

Suggested fixes (any of)

• Detect that cwd is already a git worktree (git rev-parse --is-inside-work-tree + git worktree list) and treat it as isolated for the gate.
• Make the "isolated" path prefix configurable (allow project-local .worktrees/ or arbitrary user-defined locations).
• Allow EnterWorktree path=<cwd> to be a no-op that flips the harness's "isolated" flag, so the gate's own suggested remediation actually unblocks the agent.

Environment

• Claude Code background session, model: Opus 4.7 (1M context)
• macOS Darwin 25.4.0
• Repo uses local .worktrees/<branch>/ convention (created via standard git worktree add, listed by git worktree list)