How your code and prompts are handled depends on your account type and settings. Under commercial terms (Team, Enterprise, Claude API), Anthropic doesn’t train models on Claude Code data unless the customer opts in. On consumer plans (Free, Pro, Max), you choose whether your data can be used to improve models, and retention depends on that choice. With Amazon Bedrock, Google Cloud, or Microsoft Foundry, the provider’s own terms also apply. Before using Claude Code with company code, check the data policy for your account and your employer’s rules. Details: Claude Code data usage.
Tested on Claude Code v2.1.308 on macOS, October 2026. Settings keys and their behavior change between versions, so check them against the docs for the version you run.
Personal settings and company policy. The settings below go in your personal ~/.claude/settings.json and protect you from your own mistakes. Company policy (managed settings) takes precedence over them; you can check whether it’s in effect with /status. Scope. This is a personal hardening checklist for a developer machine (macOS, Linux, WSL2), not a corporate security policy. In a company, it complements — but doesn’t replace — managed settings deployed by IT, the right account or cloud provider, and control over which tools, MCP servers, secrets, and data a session can reach.
The configuration below sets up both layers: section 1 covers Claude’s built-in tools, section 2 covers the sandbox and the git and docker exceptions.
User settings live in ~/.claude/settings.json (on Windows, %USERPROFILE%\.claude\settings.json) and apply to all your projects. Add deny rules to ~/.claude/settings.json for .env files, keys, and the ~/.ssh, ~/.aws, and ~/.kube directories — this blocks Claude from reading secrets. Then use /permissions to confirm the rules are listed.
If your sessions start in auto mode (your settings.json contains "defaultMode": "auto"), change the value to "default" and sessions will start in Manual mode. Shift+Tab will switch to auto only if that mode is available to you.
Open the file with nano ~/.claude/settings.json and add the permissions block (if the block already exists, merge it with the existing one):
Limitation. Deny rules apply to Claude’s built-in tools and to commands Claude Code recognizes (cat, head, sed, etc.). A script that opens a file on its own (for example, in Python or Node) won’t be stopped by these rules. That’s what the sandbox protects against — see the next section.
The sandbox isolates the commands Claude runs in the terminal. Deny rules in permissions hide secrets from Claude’s built-in tools, while the sandbox hides them from the commands and scripts it runs.
Where it works. On macOS the sandbox is built into the system (Seatbelt), so there’s nothing to install. On Linux and WSL2 you need the bubblewrap and socat packages (sudo apt-get install bubblewrap socat). Native Windows and WSL1 aren’t supported; use WSL2 instead. All examples in this article were tested on macOS.
The sandbox block goes at the top level of the file, next to permissions, not inside it. Example addition:
How it all works together
Regular commands (npm install, tests, builds, scripts) run in the sandbox without prompts. They can’t see keys or tokens, and the first time one needs a new site, Claude Code asks for your permission.
git push / pull / fetch / clone and docker run outside the sandbox, and only after you’ve read and approved the command. Git uses your SSH key itself; Claude never sees the key — under the conditions described below.
Claude’s built-in tools (reading and editing files) are restricted separately by deny rules.
Important: rules for git and docker. Commands in excludedCommands run outside the sandbox with your full permissions. Your approval is the only protection here, so:
Read the entire command before approving it. Approve simple commands like git push origin feature/branch. If a command contains anything extra (--receive-pack, --exec, -c ..., &&, ;, |, an unfamiliar address instead of origin), decline it.
Never choose “Yes, and don’t ask again” for git push, git pull, or docker.
Docker effectively grants administrator rights on the machine. A command like docker run -v ~/.ssh:/keys ... mounts your keys into a container, bypassing all other protection. In docker commands and in docker-compose.yml, look for -v, --volume, --mount, --privileged, and mounts of /var/run/docker.sock.
The blocks on ~/.ssh must stay enabled both in permissions and in sandbox.credentials. They are what prevent other commands from reading the key.
Extra safeguard: use a separate SSH key with a passphrase (on macOS, ssh-add --apple-use-keychain ~/.ssh/<key>) that only has access to the repositories you need, and enable branch protection for your main branches in Git.
Network access prompts. The first time a sandboxed command needs a new site, you’ll see a “Network request outside of sandbox” prompt with three options:
Yes — allow until the end of the current session.
Yes, and don’t ask again — allow permanently, but only for the current project.
No — deny.
Allow official and expected addresses: package registries (registry.npmjs.org, pypi.org), your company’s Git server, and services the task needs. Deny and ask Claude why if the domain is unfamiliar or unrelated to the task: bare IP addresses, file-sharing and paste services, webhook sites. Be careful with broad domains like github.com: they can also be used to exfiltrate data.
The complete ~/.claude/settings.json. If you don’t have the file yet, create it with this content. If you already have one, move the sandbox and permissions blocks into it, keeping your existing settings.
If you don’t need Claude to push code or run containers, use this shorter config instead. It has no excludedCommands, so every command Claude runs stays inside the sandbox.
What’s different:
git push, pull, fetch, clone, and docker will most likely fail inside the sandbox: it can’t read ~/.ssh, and docker isn’t compatible with the sandbox. Run these commands yourself in a separate terminal tab.
Claude still writes code, runs tests and builds, and makes local commits.
git push still requires your approval, whatever your git setup.
For this version, skip step 5 (git fetch) in the verification below.
After editing the file, check the syntax and restart Claude Code:
Then, in a new session:
/status — settings are loaded; /doctor — no warnings.
/permissions — your deny and ask rules are listed.
/sandbox, Config tab — the blocked paths and excluded commands are listed.
Ask Claude to run cat ~/.ssh/config — it should be denied.
Ask it to run git fetch — you should get an approval prompt.
Ask it to run curl https://example.com — you should get a network access prompt.
If the JSON has an error, Claude Code won’t apply any rule from the file, so don’t skip the json.tool step. It doesn’t prove your Claude Code version supports every key the way this article expects. Steps 4–6 test real behavior — that’s the actual proof. Run claude doctor in the terminal as well: it checks the installation and lists settings entries Claude Code couldn’t apply. Repeat the whole check after every Claude Code update.
Security and control
/status — a summary of the current session: Claude Code version, model, account, and where settings were loaded from. The key line for security is Setting sources: when a company policy is in effect, it shows Enterprise managed settings, with the selected source in parentheses (remote, plist, file, etc.).
/doctor (or claude doctor in the terminal) — diagnostics: checks the installation, updates, and whether settings are valid. It shows settings entries that Claude Code couldn’t apply: claude doctor lists each invalid entry with its source and field. For a policy delivered from the server, claude doctor reports the result of fetching it.
/permissions — view and manage tool permissions. The dialog shows all permission rules and the settings.json file each rule comes from. There are three types of rules: allow lets Claude Code use a tool without manual approval, ask always requests confirmation, and deny blocks use entirely. Rules are evaluated in the order deny, then ask, then allow, and the first match determines the outcome. Worth cleaning up accumulated permissions once a month.
/sandbox — enable and configure the sandbox for Bash commands. The sandbox lets you define in advance which files and network domains commands can access, and the operating system enforces that boundary on every Bash command and its child processes. The command opens a panel with the tabs Mode (how sandboxed commands are approved), Overrides (whether commands that fail in the sandbox can run outside it), and Config (the resolved sandbox settings, including blocked paths).
/mcp — manage MCP servers, i.e. external tools connected to Claude (Jira, databases, a browser, etc.). It shows the list of servers, their status (connected, failed, needs authentication), and each server’s tools. This is also where you authenticate with remote servers and enable or disable them.
/hooks — which hooks are configured and for which events. Useful for spotting unwanted hooks, especially after cloning someone else’s repository.
/plugin — installed plugins and marketplaces: enable, disable, remove.
/login, /logout — sign in and switch accounts. Make sure you’re using your work account.
/bug — report a problem or suspicious behavior to Anthropic.
Context and memory
/context — how much context is used and by what: files, tools, MCP. Helps you notice if something unwanted got into the session.
/clear — clear the context and start fresh. Do this when switching tasks, especially if the previous one involved sensitive data.
/compact — compress the conversation history when a session gets long.
/memory — open the CLAUDE.md files with instructions for Claude. Don’t store secrets in them.
/init — create a CLAUDE.md for the project: Claude studies the code and describes its structure.
Sessions and working directories
/resume (or claude --resume) — return to a previous session.
/rewind — roll the conversation and code changes back to an earlier point.
/add-dir — grant access to another folder. Don’t add your entire home directory.
/cd — move the session to another folder. Note that the new folder’s settings, hooks, and MCP servers take effect when you move.
Model and usage
/model — choose a model.
/cost or /usage — token usage and limits.
/config — settings menu: theme, modes, interface behavior.
Keyboard shortcuts
Shift+Tab — switch permission mode (Manual, accept edits, plan).
Esc — stop Claude mid-action.
Esc twice — go back to a previous message and edit it.
Tab on a permission prompt — add a comment for Claude to your “yes” or “no” answer.