isolation:"worktree" agent dispatch: orphaned process observed executing from a worktree path later reused by a different session
Summary
Using the Agent tool with isolation: "worktree" (subagent_type: general-purpose) to dispatch a worker session, the harness assigned it a fresh worktree at a path of the form .claude/worktrees/agent-<hash> (concretely, agent-a247e4c9bba63924a).
While that worker was mid-task on its own, unrelated work, ps aux on the host showed a process running with an absolute path rooted inside that same worktree directory, invoking a project script with arguments (a PR number, an agent id, an "approve" verdict) that belonged to a completely different, already-merged pull request from a different session identity. The current worker's own session transcript had zero references to that PR, that script invocation, or that agent id anywhere — it did not run this command.
Why this doesn't look like the "two sessions assigned the same directory at once" case
We could reproduce/verify (in the downstream repo, details below) that:
- The worktree in question was, at investigation time, cleanly checked out to the current worker's own branch, up to date with its own remote, working tree clean — i.e. it was genuinely and exclusively this worker's checkout by the time we looked.
- The other session (the one whose command referenced the unrelated PR) had its own separate, pre-existing worktree elsewhere on disk, which was found to be significantly behind
origin— consistent with a long-idle, previously-used checkout rather than something concurrently active. - No process matching that command was still running by the time we checked, and the unrelated PR's review state on GitHub showed no effect from the command (no new review was actually recorded) — so this specific instance caused no damage.
Put together, this looks less like two sessions colliding on the same path at the same instant, and more like: a process from an earlier, already-finished (or abandoned) session kept running past that session's lifetime, with an absolute path that happened to resolve into a worktree directory that was later handed out again (or whose name/hash was reused) for a new, unrelated dispatch. In other words, a process-lifecycle leak on session teardown, rather than an allocator returning a currently-live path to two callers at once.
What we're asking
- Does the
isolation: "worktree"allocator ever reuse or recycle worktree directory names/paths across separate dispatched sessions (immediately, or after some idle period)? - When a dispatched
Agent(isolation: "worktree")session ends (completes, is stopped, or is abandoned), is there a guarantee that all child/background processes it spawned are terminated before that worktree is considered free for reuse or before its directory could be reassigned? - If there's currently no such guarantee, is that a known gap, and is there a recommended way for a downstream project to detect an orphaned process rooted in a stale worktree path (short of a raw
ps auxscan of the host) so it isn't relying on manual detection?
We're not asking for API keys, hashes, or any repo-identifying details beyond what's above — happy to share more (exact ps aux line, timestamps) if useful for reproduction; just didn't want to paste an internal repo's data into a public issue unprompted.
Impact if left unaddressed
In this instance the leaked process's action (a review "approve" verdict call) had no effect because of how the target repo's tooling validates review authorship — but the underlying mechanism (a background process from a finished/abandoned session, still holding valid credentials/context, executing against a path now reassigned to different work) is one where a future instance could plausibly have side effects if the downstream tooling it's calling into is less defensive.
Environment
- Claude Code / Agent SDK,
Agenttool,isolation: "worktree",subagent_type: "general-purpose". - macOS (Darwin 24.4.0) host running multiple concurrent worktree-isolated sessions against the same git repository.