Worktree edits can silently land in the parent repo checkout (nested .claude/worktrees/ + no out-of-worktree write guard)

Summary

When working in a Claude Code-managed git worktree, file edits can silently be written to the parent repository checkout instead of the active worktree. The worktree stays clean, so the diff panel shows "No changes" and the preview doesn't reflect edits — while the work actually lands in a different checkout of the same repo.

Environment

• Claude Code desktop app, macOS
• Git worktrees feature, with worktrees created nested at <repo>/.claude/worktrees/<name>/

What happens

1. A worktree is created at <repo>/.claude/worktrees/<name>/ (nested inside the main repo).
2. During a task, the agent references files by the canonical repo path (<repo>/src/…) rather than the worktree path (<repo>/.claude/worktrees/<name>/src/…).
3. Because the worktree is nested inside the parent repo, both paths exist and resolve to different real files. The edit succeeds silently against the parent checkout.
4. The worktree's diff shows "No changes"; the preview shows no change — the edits are in the parent checkout (often on the default branch).

Reproduction (generic)

• Open a repo ~/projects/app, create a worktree via the app (lands at ~/projects/app/.claude/worktrees/foo/).
• Ask the agent to edit a file; observe whether the edit's absolute path includes the .claude/worktrees/foo/ segment.
• Compare git -C ~/projects/app status vs git -C ~/projects/app/.claude/worktrees/foo status — the change appears in the parent, not the worktree.

What is NOT the cause

• Sub-agent working directory is correct (the worktree).
• Search tools (glob/grep) return correct worktree-relative paths.
• The directories are real directories, not symlinks.

Root cause

The proximate trigger is the agent emitting a parent-rooted absolute path. Two product conditions make that silently destructive:

1. Worktrees are nested inside the repo, so the canonical repo path is a valid-but-wrong write target.
2. There is no guard that warns/blocks when a write resolves outside the active worktree root.

A stale local default branch makes it especially hard to notice, since the wrong checkout's file content looks plausible.

Suggested fixes

1. Guardrail (highest value): warn or refuse when a file write resolves outside the active worktree root — especially into another checkout of the same repo.
2. Worktree placement: consider creating worktrees outside the repo tree (sibling/external dir) so the parent doesn't contain the worktree.
3. Path handling: prefer worktree-relative paths in tool output, and discourage/normalize absolute paths that fall outside the active worktree.