CLAUDE(7) Savvy Admin Process Reference CLAUDE(7)

NAME

claude — Claude Code command-line agent: reads, edits and runs commands in a project directory with the permissions of the user who started it, filtered by the session's permission mode.

kind: ai agent · package: @anthropic-ai/claude-code (npm) or the native installer · binary: claude — a native binary since 2.x (npm puts it at node_modules/@anthropic-ai/claude-code/bin/claude.exe, an ELF file despite the name); older releases ran as a node process · config: ~/.claude/settings.json, .claude/settings.json, .claude/settings.local.json, .mcp.json, ~/.claude/.credentials.json · updated 2026-10-20

docs last verified 2026-10-20 — 0 days ago

SAFE TO KILL?

VERDICTYES. It is an ordinary user process: Ctrl-C or kill -TERM stops it. The only things it can leave behind are a half-applied edit and a child command that was already running, so check git status, git diff and its leftover children afterwards. Killing it revokes nothing it was allowed to do while alive; that is a permissions question, below.

SYMPTOMS

· a claude process at high CPU for minutes: almost always a build or test suite it launched, so look at its child processes, not at claude
· unexpected listening sockets or outbound connections: an MCP server a session started, which is a separate process
· files changed under a path you did not expect: acceptEdits or auto mode plus a broad allow rule, or a Bash command you approved once with 'don't ask again'

WHAT IT CAN DO

Everything your Unix user can do, filtered by the permission mode. Manual mode (config value default): read-only tools and a built-in set of read-only commands such as ls, cat and git status run without asking; file edits, other Bash commands, curl and wget, web fetches and searches prompt. acceptEdits adds file edits and mkdir, touch, mv, cp, rm and sed inside the working directory. plan is reads only. auto, the starting mode for interactive terminal sessions since v2.1.283, hands each action to a separate classifier model that approves or blocks it; your own deny and ask rules still apply. dontAsk denies anything that would have prompted, for CI. bypassPermissions, spelled --dangerously-skip-permissions on the command line, skips the prompts entirely, including writes to protected paths such as .git and .claude; it refuses to start as root, and the docs reserve it for containers and VMs. Rules live under permissions.allow, permissions.deny and permissions.ask in the settings files; deny rules win in every mode. A claude -p session starts in manual mode (since v2.1.302) and shows neither the workspace-trust prompt nor the .mcp.json approval prompt.

DIAGNOSE

$ ps -eo pid,user,etime,args | grep -w '[c]laude' who runs it, for how long, and with which flags: --dangerously-skip-permissions or --permission-mode on the command line tells you the mode without asking the user$ ps --ppid "$(pgrep -x claude | head -1)" -o pid,etime,args its children are what it is actually executing right now: the build, the test run, the MCP servers$ python3 -c "import json;print(json.load(open('$HOME/.claude/settings.json')).get('permissions'))" the user's allow, deny and ask rules; look for broad allows such as Bash(*) and for a defaultMode of bypassPermissions. Repeat for .claude/settings.json and .claude/settings.local.json in the project$ find ~/.claude -maxdepth 1 -type f -perm /077 -printf '%m %p\n' on Linux the login lives in ~/.claude/.credentials.json with mode 0600; settings.json at 644 is normal, a group- or world-readable .credentials.json is not$ cat .mcp.json 2>/dev/null; ss -tlnp | grep -E 'node|python|uv' the project's MCP servers, and which of them are listening on a port. User-scope servers, plugins and claude.ai connectors can add more, so .mcp.json is not the whole list

HARDEN

1. Sandbox the shell commands, not just the prompts. Then run /sandbox in a session, or set sandbox.enabled to true in ~/.claude/settings.json. On Linux and WSL2 the sandbox uses bubblewrap for the filesystem (writes limited to the working directory and a temp directory) and a local proxy for the network, so only hosts in sandbox.network.allowedDomains are reachable; plain ssh and database clients that ignore proxy variables cannot connect at all. Native Windows runs unsandboxed. On Ubuntu 24.04 and later, AppArmor blocks bubblewrap's user namespaces until you add the profile from the sandboxing docs.

$ sudo apt-get install bubblewrap socat

2. Deny what you never want, in a settings file the repository cannot override. permissions.deny: ["Bash(curl *)", "Bash(wget *)", "Read(./.env)", "Read(~/.ssh/**)"] in ~/.claude/settings.json or managed settings. A Bash deny rule matches the command text as written, so /usr/bin/curl or sh -c 'curl ...' slips past it; pair it with sandbox network isolation for enforcement that does not depend on spelling.

3. Take bypass mode off the table for everyone on the box. permissions.disableBypassPermissionsMode set to "disable" in managed settings (/etc/claude-code/managed-settings.json on Linux) removes --dangerously-skip-permissions; permissions.disableAutoMode does the same for the classifier. User and project settings cannot undo managed settings.

4. One Unix user per agent. An agent running as deploy cannot read david's home, ssh keys or shell history. This is the cheapest blast-radius cut on a shared machine and it needs no Claude Code configuration at all.

5. Keep secrets out of the environment and the working tree. A Bash command that runs env or cat .env reads every token in them. Use the sandbox's credential masking or an apiKeyHelper script for the keys the agent must have, and nothing else.

6. Treat a cloned repository as untrusted input. The workspace-trust dialog lists what a folder's .claude/settings.json would grant before it applies. Headless -p sessions skip that dialog, so run them, and any repository you did not write, inside a container or VM.

IMPOSTORS

$ readlink /proc/$(pgrep -x claude | head -1)/exe a real claude resolves to the claude binary under node_modules/@anthropic-ai/claude-code/bin/ (npm install) or to the native installer's location in your home; an executable under /tmp, /dev/shm or a dot-directory you did not create is something else wearing the name$ claude --version prints the version and 'Claude Code'; a miner that borrowed the name has nothing to say here

DISTRIBUTIONS

ubuntu 22.04 and 24.04 install bubblewrap and socat from the main repositories; on 24.04 and later check sysctl kernel.apparmor_restrict_unprivileged_userns and add the AppArmor profile for /usr/bin/bwrap from the sandboxing docs if it returns 1.
any Credentials: ~/.claude/.credentials.json, mode 0600. Configuration directory can be moved with CLAUDE_CONFIG_DIR, one per account. Managed settings for all users: /etc/claude-code/managed-settings.json.

APPLIES TO

Claude Code 2.1.x on Linux, macOS and WSL2 (facts checked against the docs on 2026-10-20: auto mode default since v2.1.283, -p sessions manual since v2.1.302). Flag and setting names change between releases; see the verified date above.

SOURCES

1. Claude Code docs — Security, fetched 2026-10-20
2. Claude Code docs — Permission modes, fetched 2026-10-20
3. Claude Code docs — Configure permissions, fetched 2026-10-20
4. Claude Code docs — Sandboxing, fetched 2026-10-20
5. Claude Code docs — Authentication (credential management), fetched 2026-10-20
Machine-readable: /process/claude.json · changelog 2026-10-20: first version. The binary is native now (an ELF named claude.exe inside the npm package), which changes the impostor check compared with the node-based 1.x releases

Ubuntu 26.04 · Claude Code 2.1.304 via npm (file, permission and process checks); docs read 2026-10-20 2026-10-20 CLAUDE(7)