What is the difference?
Claude Code permissions govern which tool calls are allowed, denied or require review. The documentation separates these from prompt instructions: a sentence in CLAUDE.md does not grant or revoke tool access. Its shell rules match command text, so a rule aimed at one invocation does not create an operating-system boundary around every way to run that program.
Sandboxing constrains shell processes through filesystem and network controls. The documented scope is shell commands and their children; it is not a claim that every integrated tool runs in that same boundary. Allowed network destinations, excluded commands and writable paths still matter.
Review one concrete task
For a proposed change to an invoice formatter, write the intended result first: “Update the formatter and its local tests; return the diff and failing cases.” Then list the resources the task requires. Reading source, editing a named directory and running an inspected test script are different from installing dependencies, accessing a cloud account or publishing a branch.
The downloadable worksheet separates instructions, tool rules, shell isolation and credential exposure. Fill in actual values from your installed version and effective settings. An empty cell means unchecked. A sandbox-enabled flag alone does not resolve the rest of the worksheet.
A synthetic settings review you can reproduce
Our example contains a narrow status command, a broad Git wildcard, an npm-script wildcard, a push denial and a Docker sandbox exclusion. The local inspector produced four review items: two wildcard questions, one exclusion question and one reminder about deny-rule scope. It reads JSON and prints questions. It does not apply settings, execute those commands, emulate Claude's rule matcher or establish that this configuration is safe.
python3 review-permissions.py permissions.example.json- Synthetic settings input · JSON
- Local inspection script · Python
- Actual local output · JSON
- Permission review worksheet · CSV
Why the wildcard deserves attention
Before allowing a repository script, inspect what it runs. “Run tests” can mean a local assertion suite, a network-backed integration suite or a script with setup steps. Record the intended command and its expected writes, services and credentials. The question is the script's actual behavior, rather than how harmless its name sounds.
Our inspector deliberately flags every wildcard for review, including ones that may be reasonable in a particular environment. It is a teaching aid with false positives and omissions. A clean output would not prove a secure configuration. Native enforcement checks, organization policy and the installed version remain separate work.
Record the result without overstating it
Keep the effective configuration, task brief, version and actual approval behavior together. Check an intended allowed action and an intended blocked action in a disposable environment before relying on the configuration for sensitive work. These native checks were not run for this article. We only inspected the synthetic file locally on 10 October 2026.
For repository separation, see the Git worktree example. For plan and billing context, use the Claude Code profile. Neither a worktree nor a paid subscription changes what a permission setting actually enforces.
Sources and scope
- Claude Code: configure permissions · Read 10 October 2026.
- Claude Code: sandboxing · Read 10 October 2026.
Factual explanation and local teaching examples. Source reads and local executions have separate scopes. No native provider workflow, send, payment, deliverability result or comparative winner is claimed. Send a correction.