Worktree auto-cleanup removes a worktree still used by a running nested background agent
A subagent launched with isolation: "worktree" starts a background child agent. The child inherits the same worktree (its meta shows inheritedWorktreePath, spawnDepth: 2). The parent then finishes without changes, Claude Code auto-removes the worktree (worktreeCleanlyRemoved: true), and ~6–8 s later every tool call in the still-running child fails with "working directory ... no longer exists ... Refusing to run there".
Observed: twice on 2026-09-14, Claude Code desktop app (2.1.220 (Claude Code)), macOS, main model Opus 5, subagents Sonnet 5 (CLAUDE_CODE_SUBAGENT_MODEL). Parent subagent_type claude.
Timeline (one case):
- 06:44:58 parent agent starts in
.claude/worktrees/agent-a59a… - 06:45:44 parent calls Agent (background); child inherits the worktree
- 06:45:50 parent ends with no changes → worktree removed
- 06:45:58 child stops: worktree no longer exists
Expected: don't auto-clean (or keep the git worktree lock) while a child agent inherited the worktree and is still running. Alternatively document this and provide a way to limit nested Agent spawning.
Impact: work lost, stage re-run from scratch (tens of millions of tokens).
Related but different: #41010, #76377.