How to run Claude Code safely for server

Wetin e mean to run Claude Code safely for server

To run Claude Code safely for server, make sure say you keep its permission prompts on, run am as dedicated unprivileged user, and give unattended runs real boundary instead of just trust: use the built-in sandbox, a container, or one disposable VPS wey no get anything wey you care about. The --dangerously-skip-permissions flag dey remove the approval step between the model and your shell. That trade fit make sense for unattended work, but only inside boundary wey go limit wetin one bad command fit reach. This guide go explain wetin the flag actually change, and how to build that boundary for rungs wey dey increase isolation.

Wetin Claude Code fit do for your box

Claude Code na coding agent wey dey run for your terminal. E dey read files, write files, and run shell commands as the user wey start am. Na that one be the whole value of the tool: e fit clone a repository, edit code, run the tests, read the failure, and fix the code for loop, without you type every command. If you never set am up for server yet, running Claude Code on a VPS with tmux go cover the install and the session handling. This page go cover the power wey you dey hand am once e don dey there.

The risk na the same sentence wey you read for second time. Process wey dey run shell commands as your user fit do anything your user fit do. E fit read ~/.ssh/id_ed25519, ~/.aws/credentials, and every .env file wey your user fit open. E fit run curl and send data to any host wey the server fit reach. E fit run git push --force. The agent no get motive of its own. The danger na say one task go wrong, or say the text wey e read while e dey work carry instructions wey someone else write: like one web page wey e fetch, or one comment for issue wey dem ask am to fix. That second case na wetin dem dey call prompt injection, and na why "the model dey usually sensible" no be security plan. You must plan for the bad run, no be for the average one.

The permission system for simple words

From the box, Claude Code dey ask before e act. Reading files inside the project dey happen silently, but editing a file or running a shell command go show you the exact edit or command first and wait for you to say yes. You fit approve one action, or approve that kind action for the rest of the session. Those approvals na for session-scope: if you quit the CLI, the next session go start cautious again. For rules wey you want keep, the settings file dey hold persistent allow, ask, and deny lists. For example: allow git status, ask on git push, deny reads of .env. Deny rules always win.

This design assume say human dey watch the terminal, and for laptop, e true. For server, the point na say often nobody dey watch. You start long task inside tmux and go sleep, and an agent wey stop to ask question for 2 a.m. no go make progress until morning. The pause dey cost money and time, because an idle Claude Code session loses its warm prompt cache and the next turn go pay to rebuild am. Na that one be the honest reason why people dey reach for the skip flag for servers, and the problem wey e solve real. The rest of this guide na about how to solve am without giving up every guardrail.

Wetin --dangerously-skip-permissions change

claude --dangerously-skip-permissions dey turn the approval step off. Edits go happen without prompt. Shell commands go run without prompt. The protected-path checks wey normally dey guard sensitive locations go also skip. Your explicit deny rules still apply, and some extreme actions still go stop to ask, but the summary simple: wetin the model decide to run, e go run.

Two facts about the flag matter for server. First, e dey block when Claude Code dey run as root or under sudo for Linux and macOS, because root wey no get prompts fit change any file or service for the machine. The agent need its own unprivileged account anyway, and the flag dey enforce that. Second, the flag no dey change the model behaviour in any way. E dey remove the human from the loop and no dey change anything else, so every mistake wey prompt for don catch, e go execute now.

So na this one be the honest calculus. If you skip permissions, the security question change from "wey the agent go do something bad" to "how much damage one bad action fit do". You stop to try control every decision and start to control the blast radius. Containment na the answer, and e dey come for rungs.

The built-in Claude Code sandbox

Before the rungs, know say Claude Code now dey ship OS-level sandbox for the commands wey e dey run, and e dey remove most of the reasons why people dey reach for the skip flag. For Linux, e dey use bubblewrap for filesystem isolation, plus socat to route network traffic through a proxy. Inside the sandbox, a command fit write only to the project directory and one session temp directory, and e fit reach the network only through a proxy wey dey check every domain against an allow list. The first time a command want new domain, Claude Code go ask you.

Turn am on with the /sandbox command inside a session. For Ubuntu and Debian, install the two packages wey e need first:

sudo apt install bubblewrap socat

For Ubuntu 24.04 and later, the default AppArmor policy dey stop bubblewrap from creating the user namespaces wey e need. The sandbox panel go tell you when something dey missing, and the Claude Code sandboxing documentation carry the short AppArmor profile wey go fix am.

The sandbox get an auto-allow mode: sandboxed commands dey run without any prompt, because the enforced boundary don do the work wey the prompt dey do before. Commands wey no fit run inside the sandbox go fall back to the normal permission flow, so the genuinely unusual actions still go ask. For most server workflows, this na the correct replacement for the skip flag, because you go get far fewer questions with an OS-enforced boundary instead of none.

Be honest about its limits. By default, a sandboxed command fit still read most of the filesystem, including credential files, unless you deny those paths; the sandbox.credentials setting dey exist exactly for that. The network proxy dey check domain names and e no dey inspect the traffic itself, so a broad allow like github.com still dey leave room to move data out. Docker no dey work inside am. The sandbox dey raise the floor plenty. E no be complete isolation boundary, na why the rungs below still matter.

The containment ladder

Three rungs, wey dey increase for isolation. Pick the lowest one wey match wetin else dey live for the box.

Rung 1: a dedicated unprivileged user. The agent get its own account, its own home directory, its own project directory, and no sudo:

sudo adduser --disabled-password --gecos "" agent

The account boundary dey keep the agent out of your files: your SSH keys and every other project for the machine. E also make the skip flag usable at all, since the flag refuse to run as root. Na the same principle as running every service as an unprivileged user, wey dem apply to agent. Wetin rung 1 no dey bound: the network, and anything for the box wey be world-readable.

Rung 2: a container. Anthropic dey publish a reference devcontainer wey dey run Claude Code as a non-root user, with firewall rules wey dey limit which hosts the agent fit reach, and a container wey you build yourself dey do the same job. The filesystem shrink to the volumes wey you mount, and egress shrink to wetin the container rules allow. Na the right middle rung when the server dey host other services wey you care about. Its limit na say containers dey share the host kernel, and one careless mount fit spoil the boundary; hand the container /var/run/docker.sock and e fit reach the whole host.

Rung 3: a dedicated VPS. The strongest rung na the bluntest: give the agent one entire machine wey no get anything wey you care about. Small VPS dey cost few dollars per month. Set am up with the first ten minutes on a new VPS runbook, snapshot the clean state, and let the agent work. Nothing else dey live there. No personal SSH key, only one deploy key wey scope to the one repository. No cloud credentials, no production data. When one run go wrong, or when you just want clean slate, restore the snapshot or destroy and rebuild the box for minutes. The blast radius na the rent. Na this setup wey --dangerously-skip-permissions stop to dey scary, because the worst realistic outcome na a rebuilt server and one revoked token.

The rungs dey stack. A sandboxed agent, wey dey run as an unprivileged user, on a disposable VPS, no dey cost much extra and e dey make failure stories boring. Boring na the goal.

Protect the credentials

The rule wey dey pay for everything else: the agent user must no fit read secrets wey belong to anything else.

Give the API key to the agent and to nothing else. Put am in one file wey the agent user own with mode 600, and load am when a shell start:

install -m 600 /dev/null /home/agent/claude.env
echo 'export ANTHROPIC_API_KEY=your-key-here' >> /home/agent/claude.env
echo 'source ~/claude.env' >> /home/agent/.bashrc

Then close the other direction. For Debian and Ubuntu, home directories dey often create wey every user for the box fit read, so tighten your own: chmod 750 /home/youruser. Check with ls -ld /home/* and fix anything the agent account fit list.

Scope every token. One fine-grained GitHub token wey limit to one repository, or one per-repository deploy key, means say if credential leak, e go lose one project and no be your whole account. If you use the sandbox, add its credential settings so say ~/.ssh and ~/.aws dey be denied even for reads. And keep production credentials off the box entirely, because an agent no fit leak secret wey no dey there.

Git is the safety net

Every change wey the agent make for suppose be reviewable and revertable, and git dey give you both for free if the agent dey work for branch:

git switch -c agent/refactor-auth

Review the run after that with git diff main...agent/refactor-auth, merge wetin good, and delete the branch if the run no lead to anything. Protect the main branch for the forge side, so that the agent token no fit push to am and e no fit force-push anywhere. The commit history dey double as an audit log of wetin happen while you sleep, wey worth more than any amount of terminal scrollback.

The network na part of the blast radius

An agent fit run curl. That sentence na the whole egress problem: wetin the agent fit read, e fit also send somewhere, and one prompt-injected agent fit do am. One plain unprivileged user no dey bound this at all, because any user fit reach anything the server fit reach. The sandbox dey bound am by domain through its proxy. A container fit bound am with its own firewall rules. A dedicated VPS dey bound wetin dey exist to leak for the first place, wey na the most robust answer of the three.

No try to solve egress with ufw alone. ufw dey allow all outgoing traffic by default, and writing outbound rules wey still permit apt, npm, git, and the Claude API na heavy work wey dey break quietly. Choose the boundary for the sandbox, container, or machine level instead, where one domain allow list or one bare machine dey do the same job cleanly.

If you dey build your own agent against the API instead of running Claude Code, the same thinking apply unchanged. Building an AI agent with Claude on a VPS cover that path, and its agent deserve the same dedicated user, the same scoped tokens, and the same disposable box.

Harden the box first

Whichever rung you choose, the machine itself still need the basics before the agent move in: SSH keys only, no root login, a default-deny firewall, automatic security updates. Generate your checklist here and work down am once:

FAQ

Is --dangerously-skip-permissions safe to use on a server?

No, no be by itself. The flag dey remove every approval prompt, so the first bad command go run the moment the model produce am. E dey become a defensible trade when the blast radius dey contained: a dedicated unprivileged user at minimum, and for genuinely unattended work, a container or a disposable VPS wey hold one project and one scoped token. Never use am on a machine wey hold production credentials or data wey you no fit lose.

Does Claude Code have a sandbox?

Yes. Claude Code dey ship with a built-in sandbox for shell commands, wey you fit open with the /sandbox command. E dey use bubblewrap for Linux and Seatbelt for macOS, e dey limit writes to the project directory, and e dey route network access through a proxy wey only permit approved domains. Its auto-allow mode dey run sandboxed commands without prompts, so e dey cut interruptions the way the skip flag dey do while e dey keep an OS-enforced boundary. E no be complete isolation boundary, so pair am with a dedicated user or a dedicated machine for unattended runs.

Why does the skip flag refuse to run as root?

Because root wey no get permission prompts fit modify any file and any service for the system, Claude Code dey block --dangerously-skip-permissions when e dey run as root or under sudo for Linux and macOS. The fix no be to fight the check. Create an unprivileged user for the agent and run am there; that account boundary na the first and cheapest layer of containment.

Can Claude Code read my SSH keys and .env files?

E fit read wetin the user wey e dey run as fit read, and even the sandbox default policy dey allow reads of credential paths until you deny them. So run the agent as its own user, keep your own home directory at mode 750 or tighter, deny credential paths for the sandbox settings, and keep production secrets off the machine entirely. A secret wey the box no ever hold, e no fit read or leak.

What is the safest way to run Claude Code unattended?

One cheap dedicated VPS wey dey use only for agent work: hardened for ten minutes, snapshotted clean, running Claude Code under an unprivileged user with the sandbox on, a mode-600 file wey hold the API key, one per-repository deploy key, and all work for branches wey you go review before you merge. If one run go wrong, you revoke one token and restore the snapshot, and nothing else wey you own go affect.