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

Bug Description
---
The scratchpad is described in the system prompt as "session-specific, isolated from the user's project", which reads as per-agent isolation. It is not. Every subagent spawned by one orchestrator session shares a single scratchpad directory (keyed by the parent session UUID), and a Skill launched as a background fork inherits the parent conversation's own scratchpad path. Concurrent agents that independently pick an obvious filename — preview.html, threads.json, out.png — silently overwrite each other, with no error and no warning at any layer.

Why this is worse than ordinary clobbering: the failure is silent and inverted. The path stays valid, the read succeeds, and the content is simply someone else's. An agent doing read-back verification can conclude "my artifact is correct" while looking at a sibling's, or "mine is broken" while looking at content that was never theirs.

Convergent naming is the mechanism, and it is not a coincidence. Colliding agents are working the same task off the same prompt, so they reach for the same obvious name. Telling agents to "pick unique names" cannot fix it — the collision has to be prevented by the harness.

---

Occurrence 1 — sibling subagents (parallel fan-out)

Several sibling agents spawned by one orchestrator each wrote a visual-verification harness to <scratchpad>/preview.html. One agent wrote its own specimens, opened the file, and screenshotted; a later capture rendered a sibling's specimens. location.href still reported its own path, so the natural first diagnosis was browser session bleed — a debugging cycle was spent there before checking the file:

$ grep -o 'SPECIMEN: P[0-9]*' preview.html
SPECIMEN: P22        # a sibling's, not mine
SPECIMEN: P23

The directory listing showed the collision surface plainly: preview.html, preview2.html, preview-light.html, preview-dark.html, all mtime-adjacent, authored by different agents.

Occurrence 2 — a forked Skill collides with its own PARENT

The main conversation had written <scratchpad>/threads.json and was querying it with jq. A Skill launched as a background fork inherited the parent's scratchpad path, chose the same generic filename for the same conceptual artifact, and ran:

gh api graphql ... --paginate --slurp > <scratchpad>/threads.json

The redirect truncated the file at open. The parent's next jq call failed with:

jq: parse error: Unfinished JSON term at EOF at line 1, column 18437044

That message accuses the wrong thing — it reads as "the data you fetched is malformed" or "your query is wrong". The document had parsed cleanly minutes earlier, so the natural inference was API truncation, not that another agent overwrote the file between two of the parent's own reads. The true cause was only understood much later, from the fork's transcript, where the offending redirect was the last command it ran.

Sharing a scratchpad with your own parent has no upside: a fork already inherits full conversation context, so there is nothing it needs to hand back through a shared path.

---

Suggested fix, in preference order

1. Provision per-agent scratchpad subdirectories — …/scratchpad/<agent-id>/ per spawned subagent, and a distinct directory for a forked Skill rather than the parent's. This removes the failure mode rather than asking every agent to remember. Strictly preferable.
2. If sharing is deliberate, say so in the prompt and require namespacing — amend the scratchpad description to "shared with sibling agents spawned by this session; prefix filenames with a token unique to your task", so agents namespace by default instead of after being burned.
3. Failing both, make the collision loud — refuse (or warn on) a truncating redirect onto a path another live agent in the session has written this turn.

A cheap mitigation regardless: agents doing read-back verification should confirm identity via a marker string rather than trusting the path. That is a workaround, not a fix, and it only helps agents who already suspect the problem.

Environment Info

• Platform: linux
• Version: 2.1.233
• Both occurrences reproduced on multi-agent orchestration (parallel Agent-tool fan-out; background-forked Skill)