Chip-spawned worktree sessions receive a git status snapshot listing every tracked file as a staged deletion

Environment

• Claude Code 2.1.241 (desktop app), macOS 26.5.2
• Large Rails monorepo (~4,600 tracked files), default branch checked out in the main working copy
• Sessions spawned from background-task chips (spawn_task → "start in a fresh worktree"), worktrees created under .claude/worktrees/

Symptom

Every session started from a chip opens with an injected gitStatus snapshot showing a large number of staged deletions. The session's first visible act is typically: "the status snapshot shows a large number of staged deletions, which needs investigating before any edits" — it then runs git status itself, finds the worktree completely clean, and proceeds.

Observed on every chip launch across a full day (5+ sessions), including launches with no concurrent git activity anywhere in the repository — so it is deterministic, not a race with other sessions' git operations.

Reproduction of the snapshot's shape

The reported state matches a worktree whose index exists but whose checkout has not completed:

git clone --no-checkout /path/to/repo /tmp/nocheckout-test
cd /tmp/nocheckout-test && git status --short | head
D  .agents/skills/active-admin/SKILL.md
D  .agents/skills/background-jobs/SKILL.md
...
# 4,592 lines, all 'D ' — every tracked file as a staged deletion

Hypothesis (unconfirmed — internals not observable from a session)

The gitStatus snapshot for chip-spawned sessions is captured after git worktree add registers the worktree/index but before file population completes, so it serializes the mid-checkout state. Post-launch inspection of the same worktrees from another session shows them healthy every time.

Impact

• Every chip session burns its first thinking/turn investigating phantom mass deletions.
• A less cautious agent could plausibly act on the phantom state (attempt to "restore" files, or distrust legitimate work).
• Erodes trust in the snapshot generally — sessions learn to re-verify it, defeating its purpose.

Suggested fix

Capture the snapshot only after the worktree checkout completes (or re-capture/suppress it when the worktree is mid-creation).