Use allowedTools to Restrict What Claude Can Do in Sensitive Contexts
Sometimes you want Claude to analyze code without touching it, or you're running it in CI where certain operations should be off-limits. The allowedTools setting lets you control exactly which tools Claude can use.
{
"permissions": {
"allowedTools": ["Read", "Glob", "Grep", "Bash(git diff:*)"]
}
}
Put that in .claude/settings.json and Claude can only read files, search, and run git diff commands — no editing, no writing, no arbitrary shell commands. Perfect for a read-only review mode.
On the command line, pass it directly:
claude --allowedTools "Read,Glob,Grep" -p "review src/ for security issues"
The tool names match Claude Code's built-in tools: Read, Write, Edit, Bash, Glob, Grep. You can also allow specific bash commands using patterns:
# Only allow running tests and reading files
claude --allowedTools "Read,Glob,Grep,Bash(npm test:*),Bash(php artisan test:*)"
This is especially useful in a few scenarios:
- CI pipelines — let Claude review code but not modify it
- Code audits — analysis only, no changes
- Onboarding — restrict new team members' Claude sessions to safe operations
- MCP tool control — allow specific MCP tools while blocking others
You can also use deniedTools for the inverse — allow everything except certain tools:
{
"permissions": {
"deniedTools": ["Bash(rm:*)", "Bash(git push:*)"]
}
}
Full access is the default, but the safest Claude Code session is one where you've defined the boundaries upfront.
via Claude Code
Log in to leave a comment.
When Claude writes error messages, button labels, validation text, or onboarding flows, it defaults to generic developer-speak. Add a "Users" section to your CLAUDE.md describing who your actual users are — their technical level, industry jargon, and what they care about — so Claude writes copy that makes sense to THEM, not to developers.
Use the --agent flag with custom markdown files in .claude/agents/ to launch purpose-built Claude sessions with restricted tools and scoped system prompts.
Every project has traps — the billing module that silently fails if you forget to queue the job, the legacy table with column names that don't match the model, the config value that must be set before tests run. Document these gotchas in your CLAUDE.md so Claude avoids the same mistakes your team spent days debugging.