Guide · Claude Code CLI and IDE · Advisories counted on 29 October 2026

Claude Code security, read from 32 advisories.

Short answer. Claude Code asks before it edits or runs anything in Manual mode, but three defaults need changing on a work machine: the sandbox is off, Bash permission rules match command text rather than programs, and a repository can ship hooks, environment settings and MCP servers. The 32 security advisories published for the CLI since June 2025 fall mostly in those gaps: 8 let repository content run before or around the trust dialog, 8 slipped a command past the approval prompt, 7 crossed the file boundary. Turn on the sandbox in strict mode, deploy managed settings, and require at least version 2.1.260.

What does Claude Code protect by default?

A session starts in a permission mode. In Manual mode Claude Code begins read-only: it runs a built-in list of read-only commands such as ls, cat and git status, and asks before every edit, every other command and every web fetch outside a short list of documentation domains. Auto mode, now the built-in starting mode for interactive terminal and VS Code sessions, sends actions to a separate classifier model that blocks the ones it judges unsafe. Your own ask and deny rules still apply, and an organization can turn auto mode off.

Several protections hold in Manual mode whatever the rules say. Unmatched commands require approval (fail-closed matching). curl and wget are never auto-approved by default. A command Claude Code cannot fully parse prompts even if part of it matches an allow rule. WebFetch hands Claude the answer of a separate model call over the page, not the raw page. Credentials go to the macOS Keychain, a 0600 file on Linux, or your profile directory on Windows.

Two defaults are weaker than they look. The working-directory boundary is a permission prompt, not an operating-system rule: a Bash command you approve can write anywhere your account can. And the sandbox, which is that operating-system rule, is off until you turn it on.

What do 32 published advisories show?

The anthropics/claude-code advisory page listed 36 advisories on 29 October 2026. Four concern Claude Desktop. The other 32 concern the CLI and its IDE extensions, from 23 June 2025 to 26 October 2026: 25 rated high, 4 medium, 3 low, and 19 of them published in 2026. We grouped them by what broke.

Three conclusions follow. First, the approval prompt is the layer that failed most often, so it cannot be the only one. Second, a repository is executable input: eight advisories turned project files into code that ran on the developer's machine. Third, every one of the 32 has a fixed version, and the most recent fix in the list is 2.1.260. A version floor closes all of them at once; a habit of "update when prompted" does not.

Why are permission rules not a security boundary?

Bash rules match the command text Claude writes, after Claude Code splits compound commands (&&, ||, ;, pipes) and strips a fixed set of wrappers such as timeout, nice and nohup. That handling is careful: a deny on Bash(git clean *) still fires inside $(...) or a for loop. But the documentation is explicit that a rule is not a boundary around the program. These deny rules stop the first form and not the others:

• Environment runners pass everything. npx, docker exec, devbox run, mise exec and direnv exec are not stripped, so Bash(devbox run *) also allows devbox run rm -rf .. Write one rule per inner command.
• Saved approvals persist. "Yes, and don't ask again" on a Bash command writes a rule to .claude/settings.local.json at the repository root, valid in every later session and worktree. Review it with /permissions.
• Deny wins across scopes. A deny in any settings file beats an allow in any other, and nothing overrides a managed deny, not even --allowedTools.

Use rules to express intent and cut prompt fatigue. For enforcement, use the sandbox, or a PreToolUse hook that inspects the full command with your own logic.

How do you run the Claude Code sandbox in strict mode?

Turn it on with /sandbox or "sandbox": {"enabled": true}. macOS uses Seatbelt. Linux and WSL2 need bubblewrap and socat, and Ubuntu 24.04 and later need an AppArmor change so bubblewrap can create user namespaces. The /sandbox panel shows what is missing. Then close the three exits the defaults leave open:

1. It fails open when it cannot start. If a dependency is missing, Claude Code runs commands unsandboxed. failIfUnavailable: true makes it exit instead.
2. Claude can retry outside it. When a command fails in the sandbox, Claude may retry with dangerouslyDisableSandbox. allowUnsandboxedCommands: false removes the retry; the /sandbox panel calls it Strict sandbox mode. Set from managed settings or --settings, it also makes Claude Code ignore repository settings that loosen the sandbox.
3. excludedCommands run with full access. Prefer filesystem.allowWrite or one more entry in allowedDomains, which keep the command inside.

Know what the sandbox does by default once it runs:

And know what runs outside it: the built-in Read, Edit, WebFetch and WebSearch tools (they follow permission rules, so a denyRead does not stop Read and allowedDomains does not limit WebFetch), command hooks, local MCP servers, LSP servers, the status line command, apiKeyHelper, and commands you type at the ! prompt in most sessions. To put all of that behind one boundary, run Claude Code itself in a dev container, a VM or the sandbox runtime.

What does a repository run before you trust it?

The workspace trust dialog appears when you start Claude Code in a folder you have not trusted, and .mcp.json servers have their own approval prompt. Two situations skip the folder's own dialog: you trusted only a parent folder, or you ran claude -p or the SDK, which never show it.

The -p column is the one to act on: a CI job that runs Claude Code on a pull request branch runs whatever hooks and MCP servers that branch defines. The documentation gives the exits:

# A pull request branch is untrusted input. Read neither its settings nor its .mcp.json,
# and turn hooks off for this run.
claude -p "Summarise the risk in this diff" \
  --setting-sources user \
  --settings '{"disableAllHooks": true}'

--bare goes further and skips hooks, skills, commands, subagents, plugins and .mcp.json, though the project's env block still applies. Setting disableAllHooks in your user settings alone is not enough, because project settings take precedence and can set it back. A disabledMcpjsonServers entry rejects a named server in every session type.

Which managed settings should a team deploy?

Managed settings sit above user and project settings and cannot be overridden by them. Deploy them through server-managed settings, MDM, or a file: /Library/Application Support/ClaudeCode/managed-settings.json on macOS, /etc/claude-code/managed-settings.json on Linux and WSL, C:\Program Files\ClaudeCode\managed-settings.json on Windows. Claude Code no longer reads the old C:\ProgramData path, and on WSL /etc/claude-code is user-writable.

{
  "requiredMinimumVersion": "2.1.260",
  "allowManagedPermissionRulesOnly": true,
  "allowManagedHooksOnly": true,
  "allowManagedMcpServersOnly": true,
  "permissions": {
    "disableBypassPermissionsMode": "disable",
    "deny": ["Read(~/.ssh/**)", "Read(~/.aws/**)", "Bash(curl *)", "Bash(wget *)"]
  },
  "sandbox": {
    "enabled": true,
    "failIfUnavailable": true,
    "allowUnsandboxedCommands": false,
    "network": { "allowedDomains": ["github.com", "registry.npmjs.org"] }
  }
}

• requiredMinimumVersion makes older versions exit at startup (Claude Code 2.1.163 or later). 2.1.260 is the highest fixed version among the 32 advisories. minimumVersion only prevents downgrades.
• allowManagedPermissionRulesOnly, allowManagedHooksOnly and allowManagedMcpServersOnly make the managed file the only source of rules, hooks and MCP servers. The first does not lock the MCP allowlist; that takes the third.
• disableBypassPermissionsMode: "disable" removes the mode that skips every check.
• Verify on a real laptop. CVE-2026-103012 (fixed in 2.1.260) is the reason: managed settings were not applied when a stored API key was preferred over enterprise sign-in. Open /permissions and /sandbox on a managed machine and confirm the locks show up.

Add OpenTelemetry metrics for usage monitoring, and a ConfigChange hook to audit or block settings changes made during a session.

What does /security-review cover?

/security-review analyses the diff between your branch and the origin default branch for vulnerabilities such as injection, authentication problems and data exposure. It needs an origin remote. The security guidance plugin does the same during a session, on the code Claude changes. Both look at the code Claude Code writes. Neither checks how Claude Code itself is configured, which is what the rest of this guide covers.

What does a safe personal baseline look like?

For a developer without managed settings, this ~/.claude/settings.json keeps the useful defaults, adds hard limits where rules are soft, and keeps prompts on the actions that leave the machine.

{
  "permissions": {
    "disableBypassPermissionsMode": "disable",
    "deny": [
      "Read(./.env)", "Read(./.env.*)",
      "Read(~/.ssh/**)", "Read(~/.aws/**)",
      "Bash(curl *)", "Bash(wget *)"
    ],
    "ask": ["Bash(git push *)"]
  },
  "sandbox": {
    "enabled": true,
    "failIfUnavailable": true,
    "allowUnsandboxedCommands": false,
    "filesystem": { "denyRead": ["~/.ssh", "~/.aws", "~/.config/gcloud"] },
    "network": { "allowedDomains": ["github.com", "registry.npmjs.org"] }
  }
}

Then test it from inside a session: ask Claude to cat ~/.ssh/id_ed25519, to run /usr/bin/curl against a host outside the list, and to write a file in your home directory. The first must be denied, the second blocked by the proxy, the third refused by the sandbox. Run the same three on a fresh clone of a repository with its own .claude/settings.json, and check that nothing from it applies before you accept the trust dialog.