Best possible solution:

Make durable write authorization upgrade-stable by requiring exact write-tool identifiers or a versioned reapproval mechanism, while allowing broad selectors for read-only narrowing if desired.

Do we have a high-confidence way to reproduce the issue?

Yes at the source level: add a new write tool whose service or risk matches a stored broad selector, and the next policy evaluation includes it without any config change. The current registry loop and selector matcher establish this path directly.

Is this the best way to solve the issue?

No, not yet: the single fail-closed resolver and account pinning are sound foundations, but a durable authorization ceiling should not silently grow after upgrades unless maintainers explicitly choose and document that behavior.

Full review comments:

• [P1] Prevent broad policies from authorizing future writes — internal/cmd/mcp_policy.go:101-108
  When allow_write is enabled, selectors such as docs.*, write, or all are re-evaluated against mcpAllTools() at every startup. Adding a new matching write tool in a later release therefore expands an existing stored authorization without any operator config change, which conflicts with this policy being a persistent ceiling; require exact write-tool names or an explicit versioned reapproval mechanism.
  Confidence: 0.94

Overall correctness: patch is incorrect
Overall confidence: 0.92

AGENTS.md: found and applied where relevant.

Codex review notes: model internal, reasoning high; reviewed against f69b2f87a33d.

Label changes:

• add P3: This is an optional operator-governance feature rather than a current urgent regression.
• add merge-risk: 🚨 compatibility: An unchanged stored selector can resolve to additional tools after upgrading, changing an existing operator’s effective configuration.
• add merge-risk: 🚨 security-boundary: Persistent configuration can authorize writes and broad selectors may silently include future matching write capabilities.
• add rating: 🦐 gold shrimp: Overall readiness is 🦐 gold shrimp; proof is 🦐 gold shrimp and patch quality is 🦐 gold shrimp.
• add status: 📣 needs proof: The PR needs real behavior proof before ClawSweeper can clear the contributor ask. Needs stronger real behavior proof before merge: The PR reports a live authenticated MCP stdio result, but no redacted transcript, terminal capture, logs, or linked artifact is available to verify the changed behavior; after adding proof, updating the PR body should trigger review, or a maintainer can request @clawsweeper re-review. After adding proof, update the PR body; ClawSweeper should re-review automatically. If it does not, the PR author or someone with repository write access can comment @clawsweeper re-review.

Label justifications:

• P3: This is an optional operator-governance feature rather than a current urgent regression.
• merge-risk: 🚨 compatibility: An unchanged stored selector can resolve to additional tools after upgrading, changing an existing operator’s effective configuration.
• merge-risk: 🚨 security-boundary: Persistent configuration can authorize writes and broad selectors may silently include future matching write capabilities.
• rating: 🦐 gold shrimp: Overall readiness is 🦐 gold shrimp; proof is 🦐 gold shrimp and patch quality is 🦐 gold shrimp.
• status: 📣 needs proof: The PR needs real behavior proof before ClawSweeper can clear the contributor ask. Needs stronger real behavior proof before merge: The PR reports a live authenticated MCP stdio result, but no redacted transcript, terminal capture, logs, or linked artifact is available to verify the changed behavior; after adding proof, updating the PR body should trigger review, or a maintainer can request @clawsweeper re-review. After adding proof, update the PR body; ClawSweeper should re-review automatically. If it does not, the PR author or someone with repository write access can comment @clawsweeper re-review.

Security concerns:

• [high] Prevent silent expansion of persistent write policies — internal/cmd/mcp_policy.go:101
  Broad selectors are evaluated against the live registry on every startup, allowing future matching write tools to become authorized without a configuration change.
  Confidence: 0.94
• [medium] Approve stored configuration as write consent — internal/cmd/mcp_policy.go:86
  The configured policy can expose explicitly selected write tools without the previously mandatory per-process --allow-write flag.
  Confidence: 1

What I checked:

• Dynamic selector resolution: Stored selectors are evaluated against every tool returned by the live MCP registry at each startup, so service, risk, and wildcard selectors can resolve to newly added tools after an upgrade. (internal/cmd/mcp_policy.go:101, 1304bac12c46)
• Persistent broad write policy: The documentation explicitly demonstrates allow_write with docs.*, which would include any future Docs write tool registered by the binary. (docs/mcp.md:125, 1304bac12c46)
• Changed write-consent contract: A configured policy can expose its selected write tools without --allow-write, while current main documents that startup flag as always required. (internal/cmd/mcp_policy.go:86, 1304bac12c46)
• Account identity binding: The PR reuses current account alias/default/single-token resolution and pins the selected stored account into RootFlags before child commands execute; direct-token and ADC modes remain on global policy. (internal/cmd/mcp.go:65, 1304bac12c46)
• Feature provenance: The linked issue remains the canonical design request and previously asked maintainers to decide the persistent policy and ceiling semantics before implementation.
• Current-area history: Bounded log and blame attribute the current MCP, account resolution, and config paths in this checkout to Peter Steinberger. (internal/cmd/mcp.go:1, 836378754862)

Likely related people:

• steipete: Current-main history attributes the central MCP, account-resolution, and config paths to Peter Steinberger, who also authored this policy implementation. (role: MCP and account/config feature owner; confidence: high; commits: 836378754862, 1304bac12c46; files: internal/cmd/mcp.go, internal/cmd/account.go, internal/cmd/mcp_policy.go)

• 🦀 challenger crab: rare, exceptional readiness with strong proof, clean implementation, and convincing validation.
• 🦞 diamond lobster: very strong readiness with only minor maintainer review expected.
• 🐚 platinum hermit: good normal PR, likely mergeable with ordinary maintainer review.
• 🦐 gold shrimp: useful signal, but proof or patch confidence is still limited.
• 🦪 silver shellfish: thin signal; proof, validation, or implementation needs work.
• 🧂 unranked krab: not merge-ready because proof is missing/unusable or there are serious correctness or safety concerns.
• 🌊 off-meta tidepool: rating does not apply to this item.

Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics.

• ClawSweeper keeps one durable marker-backed review comment per issue or PR.
• Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
• A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
• PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
• Maintainers can also comment @clawsweeper review to request a fresh review only.
• Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
• Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
• Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.