Claude Code Security: What to Set Up First — A Practical Order for Sandboxing, Permissions, and Scanning

July 28, 2026Updated: July 28, 2026Articles

A post from a Claude Code user who had actually tried setting up its security features was getting attention. The main takeaway was that installing a security plugin is not the end of the story.

Claude Code is an AI tool that can run terminal commands and edit multiple files. That is what makes it useful, but it also means that a malicious instruction inside a file—or an overly broad permission granted by mistake—could affect other files or credentials on your computer.

Rather than reproducing the post verbatim, this article compares its points with Anthropic’s official documentation. It explains what each protection is designed to guard, and where I would start if I were setting it up for my own local workflow.

“Claude security” is not a single feature

This is the post that prompted this article.

The full Claude Code security setup guide (in Japanese)

The post mainly discusses the following Claude Code features:

Permission system: asks for approval before editing files or running commands
Sandbox: separates where commands can read and write from the networks they can reach
security-guidance plugin: checks Claude’s code with pattern detection and LLM-based review
Claude Security plugin: performs a deeper multi-agent scan of an entire repository or a set of changes

The important point is that these features cover different areas. A sandbox limits what Claude’s processes are allowed to do; it does not look for vulnerabilities in the code. Security plugins do look for code problems, but they do not automatically stop a process from reading a credential file in the first place.

Start with Claude Code’s built-in protections

Anthropic’s official documentation describes Claude Code as read-only by default, asking for permission before edits and command execution. A trust check is also performed when you first work with a project.

However, repeatedly clicking “Allow” can lead to approval fatigue—the habit of approving requests without reading them carefully. This is where sandboxing becomes useful.

The sandbox separates files and networks

On macOS, Claude Code’s sandbox uses the operating system’s isolation features to constrain Bash commands and their child processes. It primarily controls two things:

Filesystem isolation: limits writes outside the working folder
Network isolation: limits which domains the process can connect to

Neither layer is enough on its own. If a file can be read but data cannot be sent outside, the impact is limited. If an external connection is available but secret files cannot be read, there is less to exfiltrate. Combining both layers reduces the paths through which a problem can spread.

Run /sandbox during a Claude Code session to open the sandbox settings. Instead of immediately maximizing automatic approvals, I recommend leaving normal confirmation in place at first and checking that the commands and domains you actually need work as expected.

Credentials are not automatically protected in every location

This is one of the most important points in the discussion. The official documentation says there is no built-in deny list for every credential on your machine; only the files and environment variables you explicitly list are restricted.

In other words, denying access to ~/.ssh does not necessarily protect your GitHub CLI settings or every cloud-provider configuration file. You need to identify the credential files and environment variables you actually use, then add them to the sandbox credential settings.

The order I would use for setup

If I were running Claude Code locally on a Mac, I would use this order:

Start Claude Code from the project subdirectory
Use /sandbox to review the filesystem and network boundaries
Deny access to credential files and tokens
Add Read/Edit deny rules where needed
Only then add a code-review plugin

A minimal example for the user settings file (~/.claude/settings.json) looks like this. Replace the paths and environment variables with the ones that exist in your own environment.

{
  "sandbox": {
    "enabled": true,
    "credentials": {
      "files": [
        { "path": "~/.ssh", "mode": "deny" },
        { "path": "~/.aws/credentials", "mode": "deny" },
        { "path": "~/.config/gh", "mode": "deny" }
      ],
      "envVars": [
        { "name": "GITHUB_TOKEN", "mode": "deny" },
        { "name": "NPM_TOKEN", "mode": "deny" }
      ]
    }
  },
  "permissions": {
    "deny": [
      "Read(~/.ssh/**)",
      "Read(~/.aws/**)",
      "Read(~/.config/gh/**)",
      "Edit(~/.ssh/**)",
      "Edit(~/.aws/**)",
      "Edit(~/.config/gh/**)"
    ]
  }
}

sandbox.credentials applies to Bash commands running inside the sandbox, while the permissions.deny rules apply to Claude Code tools such as Read and Edit. Because they protect different paths, there is value in configuring both.

Do not simply copy this configuration and assume you are finished. If you use GitHub CLI or npm, the authentication method and allowed domains may affect whether commands work. When something fails, check the required path or domain one at a time instead of removing all restrictions at once.

Should you install security-guidance?

security-guidance is an official plugin that checks for dangerous patterns and reviews diffs while Claude is writing code. Install it with:

/plugin install security-guidance@claude-plugins-official

It is worth trying if you use Claude Code regularly and want to automate a check immediately after code is written. It is not a replacement for the sandbox. It also sends diffs to an LLM for review, so check your plan and data-handling requirements before using it with highly confidential code.

A plugin in the official marketplace is not automatically something you should trust without inspection. Keep the habit of checking what files it adds, what it reads, and what network connections it makes.

Should individuals use Claude Security right away?

There are two things with similar names:

Claude Security plugin: scans a repository or a diff with multiple agents inside a Claude Code session. It currently requires a paid plan, Python 3.9.6 or later, and other prerequisites.
Claude Security managed product: an Enterprise-oriented service for continuously monitoring repositories.

For a small personal site, there is no need to sign up for a managed product immediately. A practical order is to start with the sandbox and credential denies, add security-guidance if useful, and run the Claude Security plugin before a public release or a large change.

If you want to try the Claude Security plugin, run the following inside Claude Code:

/plugin install claude-security@claude-plugins-official
/reload-plugins
/claude-security

When the scan creates a patch, the change is not applied automatically. Review the report and diff yourself, then apply it with git apply if appropriate. Having AI find a problem and accepting the change AI made are separate decisions.

Do I need this right now for the AI Jiten workflow?

If, like me, you mainly use Claude for chat and specification work and leave most implementation to Codex, there is no need to rush into every Claude Code setting. When you start using Claude Code directly on a local WordPress theme or plugin, begin with /sandbox and credential denies.

On the other hand, if Claude Code reads and writes local files or connects to GitHub and npm, I recommend setting it up. You do not need to perfect all four layers at once. These three steps already provide a meaningful baseline:

Enable /sandbox
Deny ~/.ssh, ~/.aws, GitHub CLI settings, and other credentials you use
Do not routinely use --dangerously-skip-permissions or bypassPermissions

Summary

Claude Code security is not a matter of installing one plugin and calling it done. Permissions, filesystem and network sandboxing, credential denies, and code review protect different layers: the authority given to the AI and the code it writes.

Start with sandboxing and credential denies. Add security-guidance next, and reserve the Claude Security plugin for large repositories or pre-release checks. That order is practical for most personal projects.

Security settings can make a workflow slightly less convenient. Start with a small environment where you can see what was blocked and what was allowed, then adjust the boundary to fit the way you work.