discipline:sweep-all — "make NO writes" is unenforceable: forks receive the main conversation's exact tool pool

[kyle-sexton]

Summary

plugins/discipline/skills/sweep-all/SKILL.md step 1 instructs each audit fork to "make NO
writes", and the skill's declared delta rests its safety on that property:

Audit in the forks, correct on the main thread. Parallel forks that wrote would race and
re-dilute salience; the value is one ordered correction pass.

That instruction is unenforceable by construction, and the skill does not acknowledge it.

Per https://code.claude.com/docs/en/sub-agents (fetched 2026-07-26), verbatim:

Subagents inherit the built-in tools and MCP tools available in the main conversation, narrowed
by two filters: the first removes a short list of tools from every subagent, and the second
reduces the built-in tool set for subagents that run in the background, which is the default.
Forks skip both filters and receive the main conversation's exact tool pool.

and, from the same page's fork-vs-named-subagent table, a fork's "System prompt and tools" are
"Same as main session", versus a named subagent's "From the subagent's definition file".

So a named subagent can be constrained with tools / disallowedTools; a fork cannot. N
parallel audit forks hold Write, Edit, and Bash while merely told not to use them. The declared
delta's entire safety argument is a prompt-level request, not a harness constraint, and the skill
presents it as though it were the latter.

Proposed fix

Two parts, and the honesty part is the non-negotiable one:

1. Stop implying enforcement. Say plainly in Gotchas that a fork receives the main
   conversation's exact tool pool, that no tools field can narrow it, and that "make NO writes"
   is therefore an instruction the forks are trusted to honor — not a constraint the harness
   applies. Cite the page.

2. Add the documented containment. Same page:

   When Claude spawns a fork through the Agent tool, it can pass isolation: "worktree" so the
   fork's file edits are written to a separate git worktree instead of your checkout.

   Instruct the audit fan-out to pass isolation: "worktree". This is containment, not
   enforcement: a fork that ignores the no-writes instruction lands its edits in a throwaway
   worktree rather than the user's checkout, and an audit fork that writes nothing leaves nothing
   behind. Residual risk stays and must be stated — a fork's Bash can still reach the network,
   ~/.claude, and paths outside the checkout.

Not to be claimed: the docs state nothing about isolation: "worktree" in a non-git project or
when the session is already inside a worktree. Neither behavior may be asserted; flag as
unverified rather than inventing a fallback.

Source: plugin-quality:audit post-use audit of discipline@0.9.0 (F3, HIGH).

[kyle-sexton]

This was generated by AI during triage.

Verified — every load-bearing quote confirmed verbatim

Both halves check out against sources fetched this session, not recall.

Local source. The sweep-all fan-out step does instruct each audit fork to "make NO writes", and the Gotchas do rest the declared delta's safety on it ("Parallel forks that wrote would race and re-dilute salience; the value is one ordered correction pass").

Upstream, https://code.claude.com/docs/en/sub-agents (fetched 2026-07-26), verbatim:

Subagents inherit the built-in tools and MCP tools available in the main conversation, narrowed by two filters: the first removes a short list of tools from every subagent, and the second reduces the built-in tool set for subagents that run in the background, which is the default. Forks skip both filters and receive the main conversation's exact tool pool.

The fork-vs-named-subagent table confirms the second half: "System prompt and tools" is "Same as main session" for a fork versus "From the subagent's definition file" for a named subagent. So the item's central claim holds — a named subagent can be narrowed with tools / disallowedTools; a fork cannot, and "make NO writes" is a trusted instruction, not a harness constraint. The skill presents it as the latter.

The containment sentence is also verbatim from the same page:

When Claude spawns a fork through the Agent tool, it can pass isolation: "worktree" so the fork's file edits are written to a separate git worktree instead of your checkout.

The item's own caution is correct and confirmed by omission: neither page fetched this session says anything about isolation: "worktree" in a non-git project or when the session already runs inside a worktree. Neither behavior may be asserted in the fix.

Classification and routing — cluster member of #1258

Priority: high (blocks nothing on a deadline, but a shipped correctness skill asserting a safety property the harness does not provide is a misstatement of documented harness behavior, and the finding is an input to an open structural decision). area: security applied: N parallel forks holding Write/Edit/Bash under a prompt-level request is a containment gap, and part 2 is hardening.

Routed as a decision-cluster member of #1258 (needs-human, work-class: structural), linked via a native blocked-by edge with status: needs-decision; no per-member needs-human label.

The reasoning, since this one is not obvious and the two halves split:

• Part 1 (stop implying enforcement) corrects text that is false today and stays false under any resolution. Decision-independent.
• Part 2 (instruct the audit fan-out to pass isolation: "worktree") writes new fork-specific machinery into the exact dispatch surface sweep-all-disciplines: fork subagents silently do not inherit the conversation, and two of four claimed they did #1258 is deciding whether to keep at all. Landing it ahead of that decision inverts the dependency.
• More importantly, this finding is evidence the carrier's decision needs. sweep-all-disciplines: fork subagents silently do not inherit the conversation, and two of four claimed they did #1258 asks whether the batch should dispatch forks at all or move to "named subagents plus explicit context hoisting". The fact established here — a fork cannot be tool-constrained while a named subagent can — is a direct argument in that comparison, and it should inform the decision rather than be shipped ahead of it.

If the human resolving #1258 wants part 1 carved out and landed independently, it is decision-free and ready as written; say so on this item and it can be re-routed to the autonomous-eligible role in one pass.

Role-label warning: this repository's .work-item-tracker.json has a config block with no role_labels entry, so canonical roles resolve to the plugin defaults (agent-ready / needs-human). Both default labels exist live in this repo, but the resolution is a default, not a declared binding.

[kyle-sexton]

This was generated by AI during triage.

blocked by #1258 decision — native blocked-by edge applied. Per the decision-cluster rule this member carries no needs-human label of its own; resolving the carrier's decision unblocks the cluster in one human touch. Rationale in the triage comment above.

[kyle-sexton]

Plugin-quality audit finding (interactive session, human-confirmed before posting) — doc-grounded corroboration, not a new report.

Direct current-docs confirmation of this issue's premise. https://code.claude.com/docs/en/sub-agents.md, "Control subagent capabilities" (fetched 2026-07-26):

"Forks skip both filters and receive the main conversation's exact tool pool."

This confirms verbatim that discipline:sweep-all's "make NO writes" instruction to audit forks has no tool-permission-layer backing — it is prose-only, exactly as this issue describes. No new finding; citing for the record.