[Bug] Sibling subagents share ONE scratchpad dir (and a forked Skill inherits the PARENT's), so generic filenames silently overwrite each other

Another occurrence class, from a different task shape: the shared scratchpad also carries paths to things outside it, and then the clobbering stops being confined to the scratchpad.

Two teams of four agents each ran a review/remediation pass over the same repository. Each agent worked in its own git worktree and used the shared scratchpad to record which worktree was its own. Seven incidents across the two teams:

• One agent's first measurement pass ran inside a peer's worktree — it read a path file that a peer had overwritten, so the "my tree" answer it got was someone else's. The measurement completed and looked normal.
• One agent ran a 41-row test harness in a peer's tree and had to void the entire run. Nothing failed; the numbers were simply about the wrong tree.
• One agent assembled a git worktree remove --force against a peer's path. It failed only because of an accidental prefix mismatch. Had the prefix matched, a peer's uncommitted work would have been destroyed by an agent that believed it was cleaning up after itself.
• One agent's git status reading — the evidence for a claim it was about to publish — turned out to have come from a peer's tree, and the run was discarded and re-derived in a stamp-verified worktree.

All four recovered by re-deriving after the fact, and no contaminated number shipped. But recovery cost more than the work itself, and in each case the first diagnosis was wrong for the same reason the issue body gives: the path was valid, the read succeeded, and the content was plausible — just another agent's.

The escalation worth noting is the third one. When the shared file holds a path, a collision no longer produces a wrong artifact — it produces a correctly-executed destructive command aimed at the wrong target. Uniquifying filenames by convention does not help here either, for the reason already stated: agents working the same prompt converge on the same name for the same conceptual artifact, and "the path to my worktree" is exactly such an artifact.

Adding a corroborating occurrence plus one clean repro — independent setup, same root cause.

Independent confirmation (minimal repro)

Before trusting a report of this, wanted to verify the root-cause claim (scratchpad keyed to the top-level session, not per-subagent) directly. Spawned one throwaway general-purpose subagent with nothing but: "reply with only the exact scratchpad path from your own system prompt." It returned the exact same path as the parent session's own scratchpad, byte for byte. No file writes needed — just reading the system-prompt string back from two different session contexts confirms it in one round trip.

Occurrence — git commit message corruption via commit -F, and a gap in the existing drift-detection tripwire

8 sibling agents (Agent-tool fan-out from one orchestrator), each in its own git worktree, each working an independent task off a shared backlog. One agent:

Write <scratchpad>/commit-msg-1.txt   # its own commit message
git commit -F commit-msg-1.txt        # immediately after

git commit succeeded, but git log showed a different sibling's commit message entirely — a description of unrelated work, not in this agent's diff or its worktree. The diff content itself was untouched, only the message was wrong, and it was caught by manual review of git log, not by anything at commit time.

The harness's own "commit-msg-1.txt changed on disk since you last read it" reminder did eventually fire and confirmed the mechanism — but only once the agent's own Read/Write tool next touched that path (while investigating why the log looked wrong), well after git commit -F had already consumed the clobbered content via Bash. So the existing drift tripwire (relevant to suggested fix #3 above) only covers re-entry through Claude's own file tools — it can't protect a shell command that reads the shared path directly inside the collision window. By the time the tripwire fires, the external process has already acted on the bad data. Fixed here with git commit --amend before pushing; low-stakes since it was only commit metadata, but the same window against a fixture.sql or config file consumed by a build/deploy step would ship silently corrupted state instead of just mislabeling a commit.

Net effect agrees with suggested fix #1 (per-agent scratchpad subdirectory) as the only version that actually closes the gap — namespacing-by-convention and louder-write-detection both still lose to any external, non-Claude-tool consumer racing the read.

Third occurrence, and it adds one case this issue doesn't yet name: Agent(isolation: "worktree").

Two lanes were dispatched with isolation: "worktree" to build two unrelated fixes in one repo. Git isolation worked exactly as documented — two worktrees, two branches, disjoint file sets, zero conflict, both PRs clean. Both lanes then wrote their PR body to <scratchpad>/prbody.md. Afterwards, exactly one file existed, holding the second lane's body.

$ find "$TEMP/claude/<cwd-slug>" -name 'prbody*'
.../<PARENT session uuid>/scratchpad/prbody.md     # one file, second lane's content

Neither agent worktree had a scratchpad of its own — only tasks/.

Why this case is worth calling out separately. isolation: "worktree" is the dispatch shape you reach for precisely because you want lanes that cannot interfere. It delivers loudly on the half you can see: branches, commits and diffs are all provably separate, and that visible success is what makes the invisible half so easy to miss. An orchestrator that verifies isolation by checking the branches — the obvious check — gets a clean bill every time. The guarantee you can watch working is not the guarantee that broke.

No damage here, and only by timing: the losing lane had already submitted its body at gh pr create time. A lane that writes its body and then does anything slow before creating the PR — polls CI, re-runs a duplicate scan, rebases — files the other lane's PR body, because gh pr create -F reads the file at call time rather than write time. The PR would look entirely plausible: well-formed Markdown, describing a real change, just not that one.

This matches the mechanism already described here. The scratchpad path is keyed by session id, and subagents inherit CLAUDE_CODE_SESSION_ID verbatim from the parent — so same id, same directory, with no decision point in between. Worth noting that the worktree half of this exact problem was already solved by giving each agent its own worktree; the scratchpad simply didn't get the same treatment.

Agreed that "tell agents to pick unique names" cannot be the fix. In our case both lanes were briefed from one template for one task, which is exactly the convergent-naming pressure described above — the obvious name is obvious to every lane simultaneously.