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, leave e permission prompts on, run am with dedicated unprivileged user, and give unattended runs real boundary instead of trust: the built-in sandbox, container, or disposable VPS wey no hold anything wey matter to you. The --dangerously-skip-permissions flag dey remove approval step between the model and your shell. This trade fit make sense for unattended work, but na only inside boundary wey limit wetin one bad command fit reach. This guide explain wetin the flag really change, and how to build that boundary with increasing levels of 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 the full value of this tool be that: e fit clone repository, edit code, run tests, read the failure, and fix the code for loop, without you typing every command. If you never set am up for server yet, run Claude Code for VPS with tmux explain the install and session handling. This page explain the power wey you give am once e dey there.

The risk still dey the same if you read that sentence again. Process wey dey run shell commands as your user fit do anything wey 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 go any host wey server fit reach. E fit run git push --force. The agent no get motive of im own. The danger na say task fit go wrong, or text wey e read while e dey work fit carry instructions wey another person write: na web page wey e fetch, or comment for issue wey dem ask am make e fix. Dem dey call this second case prompt injection, and na why "the model dey usually sensible" no be security plan. Instructions fit still come from near home, because two Claude Code sessions for the same box fit send text to each other, and message from sibling session na just more text wey the receiving agent dey read. You plan for bad run, no be the average one.

The permission system for simple words

As e come, Claude Code dey ask before e act. E fit read files inside the project without asking, but if e wan edit file or run shell command, e go show you the exact edit or command first, then wait for your yes. You fit approve one action, or approve that type of action for the rest of the session. Those approvals na for that session only: if you quit the CLI, the next session go start with caution again. For rules wey you want keep, the settings file get persistent allow, ask, and deny lists. For example: allow git status, ask for git push, deny reads of .env. Deny rules always get priority. That default rule dey change too, because auto mode go become the default on 14 August 2026. So e make sense to know wetin each permission mode really allow before you decide which one server wey nobody dey monitor suppose run.

This design assume say human dey watch the terminal, and for laptop, na so e be. For server, the main point often be say nobody dey watch am. You start long task inside tmux and go sleep, then agent wey stop to ask question for 2 a.m. no go make progress until morning. The pause dey cost money and time, because Claude Code session wey idle dey lose its warm prompt cache and the next turn go spend money to build am again. Na the honest reason people dey use the skip flag for servers, and the problem wey e solve dey real. The rest of this guide go show how to solve am without throwing away every guardrail.

Wetín --dangerously-skip-permissions dey change

claude --dangerously-skip-permissions dey turn off the approval step. Edits dey happen without prompt. Shell commands dey run without prompt. The protected-path checks wey normally dey protect sensitive locations, dem dey skip too. Your explicit deny rules still apply, and some very dangerous actions still stop to ask, but the simple summary be this: anything wey the model decide to run, go run.

Two facts about this flag matter for server. First, e dey blocked 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 enforce this. Second, the flag no change the model behaviour in any way. E remove human from the loop and change nothing else, so every mistake wey prompt for catch before, go now execute.

So this na the honest calculation. If you skip permissions, the security question change from “agent go do something bad?” to “how much damage one bad action fit cause?” You stop trying to control every decision and start controlling the blast radius. Containment na the answer, and e come in levels.

The built-in Claude Code sandbox

Before the rungs, make you know say Claude Code now dey ship OS-level sandbox for the commands wey e dey run. E dey remove most reasons wey make people 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, command fit write only to the project directory and session temp directory. E fit reach network only through proxy wey dey check every domain against allow list. The first time command wan use new domain, Claude Code go ask you.

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

sudo apt install bubblewrap socat

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

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

Make you understand the limits. By default, sandboxed command still fit read most of filesystem, including credential files, unless you deny those paths. The sandbox.credentials setting dey exist exactly for that. Network proxy dey check domain names, but e no inspect the traffic itself. So broad allow like github.com still leave space to move data out. Docker no dey work inside am. Sandbox raise the minimum security level plenty. But e no be complete isolation boundary. Na why the rungs below still matter.

The containment ladder

Na three levels, and isolation dey increase as you move up. Choose the lowest level wey match the other things wey dey run for the server.

Rung 1: one dedicated unprivileged user. Give the agent its own account, its own home directory, its own project directory, and no sudo:

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

The account boundary stop the agent from entering your files: your SSH keys and every other project for the machine. E also make the skip flag usable, because the flag no go run as root. Na the same principle as run every service as an unprivileged user, but apply am to an agent. Wetin rung 1 no limit na the network and anything for the server wey everybody fit read.

Rung 2: one container. Anthropic publishes a reference devcontainer wey runs Claude Code as a non-root user, with firewall rules wey limit the hosts wey the agent fit reach. Container wey you build yourself fit do the same work. The filesystem reduce to the volumes wey you mount, and egress reduce to wetin the container rules allow. This na the correct middle level when the server dey host other services wey matter to you. The limit be say containers share the host kernel, and one careless mount fit remove the boundary; give the container /var/run/docker.sock and e fit reach the whole host.

Rung 3: one dedicated VPS. The strongest level na the most direct one: give the agent one complete machine wey no get anything wey matter to you. Small VPS fit cost few dollars every month. Set am up with the first ten minutes on a new VPS runbook, take snapshot of the clean state, then make the agent work. Nothing else dey there. No personal SSH key; na only one deploy key wey scope to that repository. No cloud credentials and no production data. If one run spoil, or if you just want clean state, restore the snapshot or destroy and rebuild the server within minutes. The blast radius na the rent. For this setup, --dangerously-skip-permissions no too frightening again, because the worst realistic result na rebuilt server and one revoked token.

You fit combine the levels. Sandboxed agent wey dey run as an unprivileged user on disposable VPS cost almost nothing extra and make failure stories simple. Simple na the goal.

Protect the credentials

The rule wey dey pay for every other thing: the agent user must not fit read secrets wey belong to anything else.

Give the API key to the agent only. Put am for file wey the agent user own, with mode 600, then load am whenever 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 get read permission for every user wey dey the box, so tighten your own: chmod 750 /home/youruser. Check am with ls -ld /home/* and fix anything wey the agent account fit list.

Limit every token to the smallest scope. A fine-grained GitHub token wey limit to one repository, or a per-repository deploy key, mean say if credential leak, na one project e go affect, no be your whole account. If you use the sandbox, add its credential settings so ~/.ssh and ~/.aws dey denied even for reads. Keep production credentials completely off the box too, because agent no fit leak secret wey never dey there. If those secrets dey inside a self-hosted password manager, keep am for another box wey separate from the agent and review am separately, because Vaultwarden weak points na the admin token and the backup file rather than the encrypted vault itself.

Git na your safety net

Every change wey agent make suppose dey easy to review and revert. Git go give you both things free if agent dey work for branch:

git switch -c agent/refactor-auth

Afterwards, review the run with git diff main...agent/refactor-auth, merge the good changes, and delete the branch if nothing useful come out. Run wey touch three files dey much easier to read for breakfast pass one wey rewrite half of the module. Na why skill wey hold agent to the smallest change wey work dey useful. Protect the main branch for the forge side, so agent token no fit push go there and no fit force-push anywhere. The commit history also dey serve as audit log of wetin happen while you sleep. This one worth pass any amount of terminal scrollback.

Network na part of where damage fit spread

Agent fit run curl. That sentence explain the whole egress problem: anything wey agent fit read, e fit also send go somewhere, and prompt-injected agent fit do am. Plain unprivileged user no limit this at all, because any user fit reach anything wey server fit reach. Sandbox limit am by domain through its proxy. Container fit limit am with its own firewall rules. Dedicated VPS limit wetin fit leak from the beginning, and na the strongest answer among the three.

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

If you dey build your own agent against the API instead of running Claude Code, the same thinking still apply without change. Build AI agent with Claude for VPS cover that path, and the agent still need the same dedicated user, same scoped tokens, and same disposable box.

Harden the box first

No matter which level you choose, the machine itself still need the basic setup before the agent enter: SSH keys only, no root login, default-deny firewall, and automatic security updates. Generate your checklist here and go through am once:

FAQ

--dangerously-skip-permissions dey safe to use for server?

No be by itself. This flag dey remove every approval prompt, so the first bad command go run immediately once model produce am. E fit be reasonable trade-off if you contain the blast radius: use dedicated unprivileged user at minimum. For work wey no need person dey watch am, use container or disposable VPS wey hold only one project and one scoped token. No ever use am for machine wey hold production credentials or data wey you no fit lose.

Claude Code get sandbox?

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

Why skip flag dey refuse to run as root?

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

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

E fit read anything wey the user wey e run as fit read. Even sandbox default policy dey allow reads from credential paths until you deny dem. So run the agent as its own user, keep your own home directory for mode 750 or stricter, deny credential paths for sandbox settings, and keep production secrets completely off the machine. Secret wey the box never hold, e no fit read or leak.

Wetin be the safest way to run Claude Code unattended?

Use cheap dedicated VPS only for agent work. Harden am within ten minutes, take clean snapshot, and run Claude Code under unprivileged user with sandbox on. Keep the API key inside mode-600 file. Use per-repository deploy key, and do all work on branches wey you review before merging. If run go wrong, revoke one token and restore snapshot. Nothing else wey you own go dey affected.