/code-review finder subagents can live-reproduce a defect outside the working tree, and a project has no way to constrain them

Suggestion, not a bug report

A /code-review finder subagent performed a live reproduction of a suspected defect and, in doing so, mutated state outside the working tree — a machine-global git hooks directory owned by the user, not by the repository under review.

What happened. The diff under review was a change to an installer script. One of the review's finder agents (correctness angle) ran that installer against a scratch repository to confirm the finding empirically. The scratch repo had no local core.hooksPath, so git resolved the global one, and the installer wrote there — outside the repo, outside the review's subject. Effect in this instance was benign (one file's mode bit changed, no content difference, reverted immediately and verified), but the same reproduction shape could have overwritten real user files.

Why I am not calling it a bug. A reviewer that reproduces a finding instead of asserting it is the behaviour I want, and nothing in the skill promises read-only finder agents. My own project's rule — "review workers are read-only; live reproduction happens in a sandboxed scratch clone" — reaches only the agent prompts my project composes itself (my own pre-PR flow injects it). When the skill composes its own fan-out, that rail has no way in. That is the gap I am reporting: not the behaviour, but the absence of a way to constrain it.

Suggestions, in order of how useful they would have been here:

1. Have the built-in finder-agent template carry an explicit line on live reproduction: run it in a scratch clone, never against paths outside the working tree, never against anything that resolves a user-global config (git global config, $HOME dotfiles, system hook paths).
2. Let a project opt into extra text for the review's own subagent prompts (a per-project file the skill appends), so a project-specific rail like mine can reach them.
3. At minimum, document that /code-review finder agents may execute commands with the session's full permissions — so a project can decide whether to run it on diffs that touch installers, hooks or anything user-global.

Context: a shell-heavy repository; the reviewed change was itself a fix to an installer's never-clobber behaviour, so the review was correctly suspicious and correctly empirical. Review depth max (10 finder angles). The incident was self-caught by the session and reverted within the same turn.