Read-only code-reviewer subagent: do you restrict tools per subagent role?
I keep 12 Claude Code subagents in a project's .claude/agents/, one file per role. Each file only decides four things: name, a description saying when to delegate, the allowed tools, and the model.
Two choices I'm unsure about:
1) Tool restriction. My code-reviewer has tools: Read, Grep, Glob, Bash (no Write or Edit) and model: sonnet, and its prompt says "you review and report, you do not fix". The idea is that it can only return findings. But Bash is still there so it can run git diff and the tests, which means it could in theory rewrite a file with sed or git checkout. So "read-only" is only soft. Would you drop Bash and lose the diff/test run, or keep it and trust the prompt?
2) Model per role. I give opus only to planner-researcher and security-auditor (the judgement-heavy ones) and sonnet to the rest. The chain is plan, then design if needed, then implement, then tester, then code-reviewer. I haven't measured whether the reviewer on opus would catch more.
The screenshot is the settings view where I edit these files (I'm the maker of PMDesk, so I'm biased about the tooling, but the question is about the config itself).
How do you split roles and tool access? Fewer, broader subagents, or many narrow ones like this?
Replies
i'd keep bash and move the read-only part out of the prompt into a hook.. a prompt line is the first thing to go when the fix looks easy, a hook that blocks writes doesn't care how easy it looks. that has held for us where lines in claude.md never did. we also give each agent its own worktree so a stray sed lands somewhere you can throw away. is your reviewer reading the same checkout the implementer writes to?
On 1, I'd drop Bash from the reviewer and move the running to the tester you already have. The tester runs git diff and the tests, the reviewer gets the diff and the test output as input and only reads. Then read-only is real and you don't lose anything. The harness I use (omp) does this with its research agent: no edit tools at all, and I trust that more than any prompt line.
On 2, the reviewer is the most judgement-heavy step in your chain, so I'd try opus there before the planner. Easy way to measure: plant two or three bugs in a branch and run the reviewer on both models against the same diff.
On 1, I'd keep Bash. Prompts get skipped the moment a fix looks easy, so in my setup the hard limits live in settings: 89 allow rules, 25 deny rules and 78 hooks that stop things before they run. On 2, I don't split models by role much. When a call really matters, I have a different model double check it.