Permissions are a security boundary, not a prompt preference. Start restrictive, then allow only the operations that a specific repository and task genuinely need.
1. Map the task’s required capabilities
Write down what the task needs: read files, edit source, run tests, access the network, invoke package managers or touch deployment configuration.
2. Deny obvious high-risk operations
Block secrets, credential files, destructive shell commands, production deployment and unrelated directories unless the workflow explicitly requires them.
3. Use ask for ambiguous actions
Actions that may be legitimate but expensive or risky—installing dependencies, broad shell commands, network access—should pause for approval rather than being always allowed.
4. Allow routine narrow actions
Let safe repeated commands run without friction when you understand them: reading the repository, editing within the workspace, running a known test target.
5. Run one boundary test
Ask Claude Code to describe what it is allowed to do, then try a harmless action in each category. Confirm denied actions really stop and approval prompts appear where expected.
Before starting, summarize the filesystem, command and network permissions available in this session. If an action is outside the routine test/edit workflow, ask before doing it. Never read credential files or deploy production.
Using a prompt to “forbid” something that should be enforced by permissions; globally allowing a shell wildcard; granting network access by habit; forgetting that repository trust can change.
Finish check
Routine repository work is smooth, but secrets, destructive commands, production changes and unexpected network actions are blocked or require explicit approval.