[potiuk]

Summary

Closes #1952.

• On the Claude Code secure setup every vetted-op write failed before it started ("Project directory ~/.claude/magpie/vetted-ops does not exist"): the sandbox cannot read ~/.claude/magpie, and a sandboxed gh could not verify TLS anyway. Skills fell back to bare gh writes, bypassing the catalogue. Both launcher forms of vetted-op are now in sandbox.excludedCommands, as vetted-op-tracker already was, and both stay in permissions.ask.
• Excluding it is safe because each operation is a fixed gh argv with no shell, parameters that may not start with -, and a body read only from the owner-only workspace — less reach than the bare gh * exclusion — and every write still prompts. sandbox-lint now fails an excluded or allowed write dispatcher that no ask rule matches.
• Security review of the first commit found that --config undid that bound: an agent-written policy could set workspace = "~/.ssh" (yours, mode 0700, so it passes the workspace check) and post a key from it to a repository it chose. vetted-op and vetted-op-tracker now refuse --config whenever an operation runs and act only on the discovered, write-denied policy. A dry run, policy and list-ops keep it, as does vetted-op-read, which refuses writes before reading the policy. This also closes the same gap vetted-op-tracker already had on main.
• A follow-up review found discovery itself starts from the cwd, so a policy planted under any directory and run from there would bypass the --config refusal (the same was true for vetted-op-tracker on main). The policy path is now write-denied everywhere with Edit(//**/.apache-magpie-overrides/tools/vetted-ops/**), enforced by sandbox-lint, and a symlink anywhere on the committed policy's path is refused, as it already was for the personal layers.
• A third review found that a directory renamed into place gets past any deny glob, since the agent picks the working directory, and that the policy was checked and then opened in a separate step. The write dispatchers now act only on a discovered policy that is byte-for-byte a copy the user placed in ~/.config/apache-magpie/vetted-ops/, which no sandboxed command or agent file tool can write. Every policy file is read with O_NOFOLLOW component by component, and the home directory comes from the password database, not $HOME.
• The old "never exclude vetted-op" rule is dropped from the setup guide, the isolated-setup-install / isolated-setup-verify checklists, the vetted-ops README, the sandbox spec and the threat model (C-E3).

Type of change

• Python package (tools/sandbox-lint, tools/vetted-ops)
• Settings (.claude/settings.json, tools/sandbox-lint/expected.json)
• Docs / skill detail files (isolated-setup-install, isolated-setup-verify)

Test plan

• prek run --all-files --skip workspace-pytest passes
• pytest passes for tools/sandbox-lint and tools/vetted-ops (run outside the sandbox: three personal-policy tests write fixtures under a .git/**/apache-magpie/tools/vetted-ops/ path the sandbox write-denies)
• New tests: both write dispatchers excluded and asked, never allowed; an excluded write dispatcher without ask, and an allowed one, are invariant errors; vetted-op * does not catch vetted-op-read; both write entry points refuse an agent-written --config before anything runs (the ~/.ssh workspace shape); dry run and vetted-op-read keep --config
• setup-isolated-setup-verify eval, step-1-classify/case-7 (fixture updated): PASS
• Full setup-isolated-setup-verify eval suite — not run

RFC-AI-0004 compliance

• HITL — every vetted-op / vetted-op-tracker write keeps its ask prompt; sandbox-lint enforces it
• Sandbox — the new exclusion reaches less than the existing gh * one, and the write entry points no longer act on a policy the agent can write
• Write-access discipline — nothing new is posted without confirmation

Notes for reviewers

• Adopters on the secure setup need the two vetted-op entries in sandbox.excludedCommands and permissions.ask (isolated-setup-update will report the drift).
• Action needed after merge: every maintainer and adopter approves their project's policy once, in their own terminal, and again after each change to it: mkdir -p ~/.config/apache-magpie/vetted-ops && cp .apache-magpie-overrides/tools/vetted-ops/config.toml ~/.config/apache-magpie/vetted-ops/<project>.toml. Until then, vetted-op / vetted-op-tracker writes are refused with the command to run. Reads are unaffected.

🤖 Generated with Claude Code