Loaded rules are evaluated by class in the order deny, ask, then allow, so a specific allow does not defeat a deny from another loaded scope. File access also depends on the primary working directory, deliberately added directories and any outside-read control. Permission modes change how eligible actions are handled, while the Bash sandbox supplies a separate OS boundary.
This workspace model is different from attaching a file to a chat. See how chat attachments differ from coding-agent workspace access.
How Claude Code permissions work
Permissions decide whether Claude Code can use a tool or resource, must ask first or must refuse. The model's intention, prompt text and project instructions do not grant access by themselves. Claude Code evaluates the applicable configuration when it is about to make a tool call.
The current Claude Code permissions documentation groups rules into deny, ask and allow classes. Deny is checked first, then ask, then allow. This class order matters more than a tempting “most specific rule wins” shortcut: a narrower allow cannot overrule a deny loaded from another applicable source.
File access depends on the rules, where the session started, whether the primary directory changed, which other directories were added and how they were added. Bash operations can additionally meet the separate sandbox boundary.
Plan the access a task actually needs
Use this worksheet before expanding access. The examples are synthetic; replace them with non-sensitive, task-specific resources and record observed behaviour.
For example, a blocked read of ../shared/reference.md calls for checking the outside-read rule and how that directory was added—not for allowing every parent directory. A proposed edit outside the project should be assessed as a separate operation with its own path and permission outcome.
| Task and route | Resource | Controls to check | Smallest useful test |
|---|---|---|---|
| Read a project note with Read | docs/example.md | Loaded deny, ask and allow rules; active mode | Confirm this file's observed result |
| Edit a test file with Edit | src/sample.txt | Read deny also blocks Edit and Write; mode does not erase deny rules | Limit the change to the named file |
| Read an outside reference with Read | ../shared/reference.md | Outside-read controls, directory-addition route and loaded rules | Add only the needed directory, then test a harmless read |
| Run a formatter with Bash | Sample source and output directory | Bash permission plus active sandbox filesystem limits | Confirm output stays within intended scope |
| Fetch documentation with WebFetch | docs.example.test | Direct web-tool rules and mode | Check this destination; no conclusion about Bash isolation |
| Contact a package service with Bash | packages.example.test | Bash permissions plus active sandbox network boundary | Check the required destination through the actual command route |
If a task is denied or repeatedly prompts:
- Identify the exact tool, action and resource that was blocked.
- Confirm the primary working directory, whether it changed, and the provenance and intended effect of every added directory.
- Establish the applicable settings sources separately from the loaded permission rules, then evaluate deny, ask and allow in class order.
- Distinguish built-in file or direct web-tool permission decisions from a sandboxed Bash denial or host operating-system restriction.
- For network activity, identify whether it is a direct web-tool call or traffic originating in sandboxed Bash.
- Choose the smallest rule or task change that resolves the legitimate need.
- Retry on recoverable material and record the observed effective access.
Working directories and outside-read controls
The primary working directory is normally the directory from which Claude Code was launched until it is deliberately changed. It supplies the central project context, but it should not be treated as an automatic statement that every operation inside is allowed or that every read outside is impossible.
Additional directories can expand file access. Their provenance matters. A directory added through settings expands file access, while a directory added for the session or at launch can also expose project resources such as skills, commands or subagents. Deliberately changing the primary directory can load the new project's configuration and trust flow. Review both the route and the final path.
Claude Code also documents blockReadsOutsideWorkingDirectories as a defensive control for restricting file-tool reads outside working directories. Its current behaviour should be revalidated before use. It is not evidence that outside reads are always blocked by default.
Deny, ask and allow rules
Rule evaluation follows class order: deny, then ask, then allow. If any applicable deny matches, a more specific allow from another loaded scope does not cancel it. Ask captures an action for review, while allow permits a matching operation when no deny or ask has already matched.
Read and Edit are distinct tool concepts, but there is an important interaction: a Read deny for a path also blocks built-in Edit and Write on that path. That helps prevent a file hidden from reading from being modified through those tools.
These rules are best-effort controls for built-in tools and recognised Bash file operations. They are not operating-system confinement for an arbitrary subprocess. That stronger enforcement question belongs to the Bash sandbox.
Permission modes: what changes and what does not
Anthropic's current permission modes reference lists Manual (default), Accept Edits (acceptEdits), Plan (plan), Auto (auto), Don't Ask (dontAsk) and bypassPermissions. The last skips most permission prompts and safety checks, although applicable deny rules and certain mandatory prompts remain. It is not an isolation boundary.
The modes change how eligible operations are handled:
- Manual follows the configured permission flow, but it is not necessarily every user's starting mode merely because its configuration value is
default. - Accept Edits reduces friction for eligible file changes. It does not cancel loaded deny rules or make an input trustworthy.
- Plan normally blocks source edits and can run classifier-approved commands where Auto is available. If bypass permissions are available to the session, its edit blocks are not enforced. Treat it as a planning workflow, not a read-only security boundary.
- Auto uses a classifier to decide whether eligible operations can proceed. It does not guarantee that a command, file or result is safe.
- Don't Ask refuses operations that would require a prompt. Operations needing no approval, or already covered by applicable approvals, can still run.
Starting behaviour can vary by plan, interface, feature eligibility, organisational policy, version and settings. Check the displayed mode and applicable rules rather than assuming Manual.
Permission Auto is also unrelated to sandbox auto-allow. The former classifies permission decisions. The latter changes approval handling for eligible Bash commands that remain under the sandbox's filesystem and network enforcement.
Two different kinds of precedence
Settings-source precedence answers: which configuration values and rules are available to this session? Managed policy can take priority where applicable, followed by the product's documented source hierarchy.
Permission-rule decision order answers: once those rules are loaded, which class wins for this tool call? The answer is deny, then ask, then allow.
Do not collapse these into one specificity calculation. A project-level allow cannot defeat an applicable managed deny merely because its path is narrower. Identify the loaded sources first, then evaluate their rules by class.
This distinction is useful when you design file access inside the wider agent harness. Configuration provenance, permissions, isolation and human review should remain visible as separate control decisions.
Expanding workspace access deliberately
When Claude Code needs a reference outside the primary directory, first decide whether the task really needs that material. If it does, add the narrowest relevant directory through the route whose side effects you understand. A settings-based addition, a session addition and a changed primary directory are not interchangeable.
Record whether the change exposes only file access or also introduces project resources and configuration. Review workspace trust when the primary project changes. Then test one harmless read and, only if required, one harmless write. Do not treat a successful read as permission to edit, execute or reach the network.
Keep sensitive files and unrelated directories outside the effective task scope. Broad access creates more material that a mistaken instruction or generated command could reach.
Built-in tools versus the Bash sandbox
Built-in Read, Edit and Write calls and direct WebFetch or WebSearch calls use permissions. Anthropic's sandboxing documentation explains how a Bash command that actually runs sandboxed additionally meets OS-enforced filesystem or network restrictions, and how its child processes inherit that boundary.
This gives two compact routing questions:
- Which file or action should Claude Code allow, ask about or deny? Use permissions.
- What constrains a Bash command and its child processes? Understand the Claude Code Bash sandbox boundary.
A permitted WebFetch call does not prove that Bash traffic can reach the same destination. Likewise, a built-in Read result does not demonstrate the read scope of a shell command. Test the actual execution route.
Diagnosing permission denials and repeated prompts
Start from the prompt or denial, not from a broad configuration change. Name the tool, resource and operation. Check whether an applicable deny or ask exists, which settings source supplied it, and whether the active mode changes the review behaviour.
Check settings precedence and permission-rule matching separately. The first determines what configuration was loaded; the second determines how the loaded deny, ask and allow rules apply to this operation.
For files, verify directory provenance and whether the operation is Read, Edit, Write or Bash. For network access, separate a direct web tool from Bash-originated traffic. If Bash is involved, an OS sandbox or host restriction may be the true blocker even when the permission rule looks permissive.
Then apply the smallest correction: a task-specific rule, an intentional directory addition, a one-time review, a narrower task or no access. Retest with a disposable file or harmless destination and retain the observed result.
Reducing friction without removing safeguards
Repeated prompts often indicate that the task is underspecified or crossing a boundary repeatedly. Group related work, name the exact files and use a task-specific allow or ask rule where appropriate. For inspection, keep the task read-focused. For an occasional external file, prefer an intentional narrow addition over expanding the main project scope.
Automated workflows may need a stable, preapproved surface, but stable does not mean unlimited. Define the permitted actions and resources, isolate the environment, and fail closed when the task needs something else. Anthropic's security guidance supports treating least privilege and environment isolation as distinct safeguards. A one-time review can be more appropriate than a lasting broad rule.
Teams can turn permission decisions into everyday AI use rules so people know which directories, data and actions require review.
Documents placed in a Claude Code-accessible workspace
When adding outside reference material to a Claude Code project, check both the access scope and the document version being introduced. Start with the document prompt-injection checklist.
.mdSiren is a document security checkpoint for AI systems: check supported prompt-injection and document-borne risks, return Approved, Needs review or Quarantine, and keep the current eligible Approved copy ready for retrieval. An accepted replacement needs its own check, with no fallback to the earlier copy while the replacement is pending or held.
Pro API access lets authorised agents submit documents, check status and retrieve eligible Approved exact versions under scoped account permissions. See the document workflow, or Coming soon. Decisions cover the reported checks; Quarantine is a document-handling state. Claude Code's permissions remain responsible for downstream access and actions.
What bypass and skip requests are really asking
A blocked build, repeated prompts or unattended automation can make removing permission checks seem convenient. Removing review can expand the effect of generated actions, but it does not validate those actions.
Diagnose the exact capability instead. Use a narrow allow rule, intentional additional directory, smaller task, read-focused workflow, one-time review or verified disposable environment. Do not override a managed deny or expose credentials and unrelated private files simply to make a task proceed.
Frequently asked questions
What files can Claude Code access?
It depends on the primary working directory, deliberately added directories, loaded deny/ask/allow rules, outside-read controls, tool route, mode and any Bash sandbox boundary. Check the exact resource rather than assuming a universal folder limit.
How does the working directory affect Claude Code file access?
It supplies the primary project context and influences file scope. Changing it can load a new project's configuration and trust flow. It does not automatically allow every operation inside or block every read outside.
What is the difference between allow, ask and deny rules?
Deny refuses a matching action, ask requires review and allow permits a match when neither earlier class applies. Claude Code evaluates these classes deny first, then ask, then allow.
What do Claude Code permission modes change?
They change how eligible tool calls are approved, classified, prompted or refused. They do not rewrite the loaded rules, prove an action safe or replace the Bash sandbox.
Does Claude Code always start in Manual mode?
No. Starting behaviour varies by plan, interface, version, feature eligibility, organisational policy and settings. Confirm the active mode in the current session.
Is Plan mode completely read-only?
No. Plan normally blocks source edits, but can run classifier-approved commands where Auto is available. If bypass permissions are available to the session, the edit blocks are not enforced. It is a planning workflow, not a complete read-only security boundary.
Is adding a directory the same as granting every kind of access?
No. The route used to add it affects what file access, project resources and configuration may become available. Separate reading, editing, execution and network requirements and retain applicable rules.
What is the difference between Claude Code permissions and the sandbox?
Permissions decide whether tools and resources are allowed, reviewed or denied. The sandbox adds OS-enforced filesystem and network boundaries to Bash commands that actually run sandboxed and their child processes.
Why does Claude Code keep asking for permission?
An ask rule may match repeatedly, the task may keep touching new resources, or the active mode may require review. Record the exact prompts, locate the responsible rule and narrow the task or rule without removing unrelated safeguards.
Should I skip or bypass Claude Code permissions?
Usually no. Find the exact blocked tool, path or destination and make the smallest supported rule, scope or workflow change. If genuinely broad access is unavoidable, use a separately verified disposable environment rather than weakening the primary workspace.
