Setup and safety

Claude Code sandbox and permission safety guide

Set practical boundaries for filesystem access, commands, secrets, network calls, and high-risk actions.

Updated 2026-07-15

Permissions should match consequence

A read-only repository review and a production migration should not share the same authority. Start with the narrowest access that can complete the task. Expand only when a concrete blocked action is understood and the scope remains acceptable.

Protect the irreversible seams

Credentials, production databases, package publication, git history rewrites, and broad deletion need explicit review. Never paste secrets into prompts or logs. Prefer dry runs, previews, backups, and commands limited to the named resource.

  • Inspect proposed commands.
  • Keep unrelated dirty files intact.
  • Use environment-native secret loading.
  • Verify external state after authorized writes.

Review generated code as untrusted input

Passing tests reduce risk but do not prove security or product correctness. Read authentication, billing, data migration, and shell-script changes closely. The owner remains responsible for the shipped result.

Primary sources

Provider terms and product behavior can change. Confirm plan, pricing, model, and permission details in the current official documentation.

Questions

Should I allow every command for convenience?

No. Approve capabilities in proportion to the task and review actions with destructive or external consequences.