spawn_task chip runs in the spawning session's working tree, not an isolated worktree — while that session is still editing it

Summary

A background task started from a spawn_task chip runs in the same working tree as the session that
spawned it, not in an isolated worktree — while the spawning session is still actively editing that tree.
The spawning session is told otherwise: spawn_task returns

A chip is showing for the user — they can start it in a fresh worktree with one click

Two chip sessions did this in one evening on the same repository. Neither created a worktree.

What happened

Working in ~/code/wolverine on a feature branch, I called spawn_task to flag an out-of-scope defect
(task_2abc4d00). The user started it, and a system reminder told me:

The user started your suggested background task task_2abc4d00 ... in a separate local session.

A separate session, yes — but the same filesystem. Its edits appeared as uncommitted modifications in
my working tree, on my feature branch, interleaved with my own in-progress changes to a different
issue. Three files I had not touched showed up under git status while I was mid-task.

It then created its own branch and committed there — still in the shared tree — which switched the branch
out from under my session. A second chip session later that evening (task_1682a38c) independently
confirmed it was in the same place, reporting "My working tree at /Users/…/wolverine is clean".

At the end, git worktree list shows only the main tree and the one I created by hand:

/Users/…/code/wolverine    [gh-4188-…]     <- main tree, left on the chip session's branch
/private/tmp/wolv-4191     [gh-4191-…]     <- created manually by me

Why it matters

Nothing was lost here, but only because I noticed unexplained files under git status and moved my own
work into a hand-made worktree before staging anything. The failure modes are ordinary:

1. Cross-contamination on commit. I had uncommitted work for an unrelated issue in that tree. Either

session running git add -A or git commit -a would have swept the other's changes into its commit
and its PR. (This repo's own guidance says never git add -A, which is the only reason my habits
protected me.)

1. The branch moves underneath you. The chip session switched branches in a tree another session was

working in. A build or test run racing that switch compiles a mixture.

1. Build contention. Two sessions running dotnet build/dotnet test in one tree fight over obj/

and bin/.

1. The tree is left parked on the chip's branch, not on whatever the user had checked out.

The spawning session has no way to know this is coming, because the tool result says the opposite.

Expected

Either:

• the chip actually uses an isolated worktree, matching what spawn_task reports; or
• spawn_task's result stops promising one, and says plainly that the task may run in the same

working tree — so the spawning session can defend itself (isolate its own work first, avoid staging
paths it does not own).

The second is a documentation fix and would have been enough to prevent the risk here. The first is what
the current wording leads a caller to expect.

Environment

• Claude Code in the desktop app, macOS (Darwin 25.4.0)
• Both chip sessions started from the chip UI, in the same repository, while the spawning session was live
• Reproduced twice in one evening with two independent chips

Note on evidence

The interleaving, the branch switch, and the absent worktrees are all directly observed — git status,
git branch --show-current, and git worktree list at the time. What I have not established is
whether the "fresh worktree with one click" path exists and was not taken (e.g. the user started the task
by some other affordance), or whether the isolation is simply not wired up. That distinction matters for
which of the two fixes above is the right one, and someone with the harness source can settle it far
faster than I can from the outside.