Paano patakbuhin ang Claude Code nang ligtas

Ano ang ibig sabihin ng ligtas na pagpapatakbo ng Claude Code sa isang server

Para mapatakbo nang ligtas ang Claude Code sa isang server, panatilihing naka-on ang mga permission prompt nito, patakbuhin ito bilang isang dedicated unprivileged user, at bigyan ang mga unattended runs ng tunay na boundary sa halip na pagtitiwala lamang: ang built-in sandbox, isang container, o isang disposable VPS na walang mahahalagang data. Inaalis ng --dangerously-skip-permissions flag ang approval step sa pagitan ng model at ng iyong shell. Ang trade-off na ito ay maaaring katanggap-tanggap para sa unattended work, ngunit dapat lamang ito gawin sa loob ng isang boundary na naglilimita sa abot ng isang maling command. Ipinapaliwanag ng guide na ito kung ano ang binabago ng flag na ito, at kung paano bubuuin ang boundary na iyon gamit ang mga rungs ng pataas na isolation.

Ano ang kayang gawin ng Claude Code sa iyong machine

Ang Claude Code ay isang coding agent na tumatakbo sa iyong terminal. Nagbabasa ito ng mga file, nagsusulat ng mga file, at nagpapatakbo ng mga shell command bilang ang user na nag-start nito. Iyan ang buong halaga ng tool: kaya nitong mag-clone ng repository, mag-edit ng code, magpatakbo ng mga tests, magbasa ng error, at ayusin ang code sa isang loop, nang hindi mo na kailangang i-type ang bawat command. Kung hindi mo pa ito na-set up sa isang server, ang pagpapatakbo ng Claude Code sa isang VPS gamit ang tmux ay sumasaklaw sa installation at session handling. Tinatalakay ng pahinang ito ang kapangyarihang ibinibigay mo rito kapag naka-install na ito.

Ang panganib ay ang parehong pangungusap na binasa nang pangalawang pagkakataon. Ang isang process na nagpapatakbo ng shell commands bilang iyong user ay kayang gawin ang lahat ng kayang gawin ng iyong user. Kaya nitong basahin ang ~/.ssh/id_ed25519, ~/.aws/credentials, at bawat .env file na kayang buksan ng iyong user. Kaya nitong magpatakbo ng curl at magpadala ng data sa anumang host na kayang maabot ng server. Kaya nitong magpatakbo ng git push --force. Ang agent ay walang sariling motibo. Ang panganib ay kapag nagkamali ang isang task, o kapag ang text na binasa nito habang nagtatrabaho ay may mga instruction na isinulat ng ibang tao: isang web page na ni-fetch nito, o isang comment sa isang issue na inutusan itong ayusin. Ang pangalawang kasong ito ay tinatawag na prompt injection, at ito ang dahilan kung bakit ang "the model is usually sensible" ay hindi isang security plan. Maghanda para sa maling takbo, hindi para sa average na takbo.

Ang permission system sa simpleng paliwanag

Sa default, nagtatanong ang Claude Code bago kumilos. Ang pagbabasa ng mga file sa loob ng project ay tahimik, ngunit ang pag-edit ng file o pagpapatakbo ng shell command ay magpapakita muna sa iyo ng eksaktong edit o command at maghihintay ng "yes". Maaari kang mag-approve ng isang action, o mag-approve ng ganoong uri ng action para sa natitirang session. Ang mga approval na ito ay session-scoped: kapag in-exit ang CLI, ang susunod na session ay magsisimula muli nang maingat. Para sa mga rules na gusto mong panatilihin, ang settings file ang may hawak ng mga persistent allow, ask, at deny lists. Halimbawa: allow git status, ask sa git push, deny ang pagbabasa ng .env. Laging mananalo ang deny rules.

Ang design na ito ay nag-a-assume na may tao na nagbabantay sa terminal, at sa isang laptop, totoo ito. Sa isang server, ang punto ay madalas na walang nagbabantay. Magsisimula ka ng isang mahabang task sa loob ng tmux at matutulog, at ang isang agent na humihinto para magtanong ng alas-2 ng madaling araw ay walang progreso hanggang umaga. Ang paghinto ay may gastos na pera pati na rin oras, dahil ang isang idle Claude Code session ay nawawalan ng warm prompt cache at ang susunod na turn ay may bayad para muling i-rebuild ito. Iyan ang totoong dahilan kung bakit ginagamit ng mga tao ang skip flag sa mga server, at ang problemang nilulutas nito ay totoo. Ang natitirang bahagi ng guide na ito ay tungkol sa paglutas nito nang hindi isinusuko ang lahat ng guardrail.

Ano ang binabago ng --dangerously-skip-permissions

Pinapatay ng claude --dangerously-skip-permissions ang approval step. Ang mga edit ay nangyayari nang walang prompt. Ang mga shell command ay tumatakbo nang walang prompt. Ang mga protected-path checks na karaniwang nagbabantay sa mga sensitive na lokasyon ay nalalaktawan din. Ang iyong mga explicit deny rules ay applicable pa rin, at ang ilang extreme actions ay hihinto pa rin para magtanong, ngunit ang working summary ay simple: kung ano ang desisyon ng model na i-run, ay tatakbo.

Dalawang katotohanan tungkol sa flag na ito ang mahalaga sa isang server. Una, blocked ito kapag ang Claude Code ay tumatakbo bilang root o sa ilalim ng sudo sa Linux at macOS, dahil ang root na walang prompts ay kayang baguhin ang anumang file o service sa machine. Kailangan ng agent ang sarili nitong unprivileged account, at ipinapatupad ito ng flag. Pangalawa, ang flag ay hindi binabago ang behavior ng model sa anumang paraan. Inaalis nito ang tao sa loop at walang ibang binabago, kaya ang bawat pagkakamali na sana ay nahuli ng prompt ay tatakbo na ngayon.

Kaya narito ang totoong kalkulasyon. Kung i-skip mo ang permissions, ang security question ay nagbabago mula sa "gagawa ba ang agent ng masama" tungo sa "gaano kalaking damage ang magagawa ng isang maling action". Ititigil mo na ang pagkontrol sa bawat desisyon at sisimulan mo nang kontrolin ang blast radius. Ang containment ang sagot, at ito ay dumarating sa mga rungs.

Ang built-in Claude Code sandbox

Bago ang mga rungs, alamin na ang Claude Code ay may kasama nang OS-level sandbox para sa mga command na pinapatakbo nito, at inaalis nito ang karamihan sa mga dahilan kung bakit ginagamit ng mga tao ang skip flag. Sa Linux, gumagamit ito ng bubblewrap para sa filesystem isolation, plus socat para i-route ang network traffic sa pamamagitan ng isang proxy. Sa loob ng sandbox, ang isang command ay maaari lamang magsulat sa project directory at sa isang session temp directory, at maaari lamang itong makarating sa network sa pamamagitan ng isang proxy na sinusuri ang bawat domain laban sa isang allow list. Sa unang pagkakataon na gustong kumuha ng command ng bagong domain, magtatanong sa iyo ang Claude Code.

I-on ito gamit ang /sandbox command sa loob ng isang session. Sa Ubuntu at Debian, i-install muna ang dalawang packages na kailangan nito:

sudo apt install bubblewrap socat

Sa Ubuntu 24.04 at mas bago, pinipigilan ng default AppArmor policy ang bubblewrap sa paggawa ng user namespaces na kailangan nito. Sasabihin sa iyo ng sandbox panel kung may kulang, at ang Claude Code sandboxing documentation ay may maikling AppArmor profile na nag-aayos nito.

Ang sandbox ay may auto-allow mode: ang mga sandboxed commands ay tumatakbo nang walang anumang prompt, dahil ang enforced boundary na ito ang gumagawa ng trabahong dati ay ginagawa ng prompt. Ang mga command na hindi maaaring tumakbo sa loob ng sandbox ay babalik sa normal na permission flow, kaya ang mga tunay na kakaibang action ay magtatanong pa rin. Para sa karamihan ng server workflows, ito ang tamang kapalit para sa skip flag, dahil mas kaunti ang matatanggap mong tanong gamit ang isang OS-enforced boundary kumpara sa wala.

Maging tapat sa mga limitasyon nito. Sa default, ang isang sandboxed command ay maaari pa ring magbasa ng karamihan sa filesystem, kabilang ang mga credential files, maliban kung i-deny mo ang mga path na iyon; ang sandbox.credentials setting ay narito para sa eksaktong dahilan na iyon. Ang network proxy ay sinusuri ang mga domain name at hindi sinusuri ang mismong traffic, kaya ang isang malawak na allow gaya ng github.com ay nagbibigay pa rin ng pagkakataon na maglabas ng data. Hindi gumagana ang Docker sa loob nito. Malaki ang itinataas ng sandbox sa level ng security. Hindi ito isang kumpletong isolation boundary, kaya mahalaga pa rin ang mga rungs sa ibaba.

Ang containment ladder

Tatlong rungs, sa pataas na pagkakasunod-sunod ng isolation. Piliin ang pinakamababang rung na tugma sa kung ano pa ang nasa machine.

Rung 1: isang dedicated unprivileged user. Ang agent ay magkakaroon ng sariling account, sariling home directory, sariling project directory, at walang sudo:

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

Ang account boundary na ito ay naglalayo sa agent sa iyong mga file: ang iyong mga SSH keys at bawat iba pang project sa machine. Ginagawa din nitong usable ang skip flag, dahil ang flag ay tumatangging tumakbo bilang root. Ito ang parehong prinsipyo ng pagpapatakbo ng bawat service bilang isang unprivileged user, na inapply sa isang agent. Ang hindi nililimitahan ng rung 1: ang network, at anumang bagay sa machine na world-readable.

Rung 2: isang container. Naglalathala ang Anthropic ng isang reference devcontainer na nagpapatakbo ng Claude Code bilang isang non-root user, na may firewall rules na naglilimita kung aling mga host ang maaaring maabot ng agent, at ang isang container na ikaw mismo ang gagawa ay gumagawa ng parehong trabaho. Ang filesystem ay lumiliit sa mga volumes na iyong i-momo-un, at ang egress ay lumiliit sa kung ano ang pinapayagan ng mga rules ng container. Ito ang tamang middle rung kapag ang server ay nagho-host ng iba pang services na mahalaga sa iyo. Ang limitasyon nito ay ang mga container ay nagbabahagi ng host kernel, at ang isang maling mount ay maaaring sumira sa boundary; ibigay ang /var/run/docker.sock sa container at maaari itong makarating sa buong host.

Rung 3: isang dedicated VPS. Ang pinakamalakas na rung ay ang pinakasimple: bigyan ang agent ng isang buong machine na walang anumang mahahalagang data. Ang isang maliit na VPS ay nagkakahalaga lamang ng ilang dolyar bawat buwan. I-set up ito gamit ang ang unang sampung minuto sa isang bagong VPS runbook, i-snapshot ang malinis na state, at hayaan ang agent na magtrabaho. Wala nang ibang nakatira doon. Walang personal na SSH key, tanging isang deploy key na limitado sa isang repository lamang. Walang cloud credentials, walang production data. Kapag nagkamali ang isang run, o kapag gusto mo lang ng malinis na simula, i-restore ang snapshot o sirain at i-rebuild ang machine sa loob ng ilang minuto. Ang blast radius ay ang renta. Ito ang setup kung saan ang --dangerously-skip-permissions ay hindi na nakakatakot, dahil ang pinakamalalang realistic na resulta ay isang rebuilt server at isang revoked token.

Ang mga rungs ay nagpapatong-patong. Ang isang sandboxed agent, na tumatakbo bilang isang unprivileged user, sa isang disposable VPS, ay halos walang dagdag na gastos at ginagawang boring ang mga failure stories. Boring ang layunin.

Protektahan ang mga credentials

Ang rule na nagbabayad para sa lahat ng iba pa: ang user ng agent ay hindi dapat makabasa ng mga secrets na pagmamay-ari ng kahit ano pang iba.

Ibigay ang API key sa agent at sa wala nang iba. Ilagay ito sa isang file na pagmamay-ari ng user ng agent na may mode 600, at i-load ito kapag nagsimula ang isang shell:

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

Pagkatapos ay isara ang kabilang direksyon. Sa Debian at Ubuntu, ang mga home directory ay madalas na ginagawa na readable ng bawat user sa machine, kaya higpitan ang iyong sarili: chmod 750 /home/youruser. Suriin gamit ang ls -ld /home/* at ayusin ang anumang kayang i-list ng account ng agent.

Limitahan ang bawat token. Ang isang fine-grained GitHub token na limitado sa isang repository, o isang per-repository deploy key, ay nangangahulugang ang isang leaked credential ay mawawalan lamang ng isang project at hindi ang iyong buong account. Kung gagamit ka ng sandbox, idagdag ang mga credential settings nito para ang ~/.ssh at ~/.aws ay ma-deny kahit para sa mga pagbabasa. At panatilihing malayo sa machine ang lahat ng production credentials, dahil hindi makakapag-leak ang isang agent ng isang secret na wala naman doon.

Ang Git ay ang safety net

Ang bawat pagbabagong ginagawa ng agent ay dapat na maberereview at ma-revert, at binibigay sa iyo ng git ang parehong ito nang libre kung ang agent ay nagtatrabaho sa isang branch:

git switch -c agent/refactor-auth

Suriin ang run pagkatapos gamit ang git diff main...agent/refactor-auth, i-merge ang mabuti, at burahin ang branch kung ang run ay walang nangyari. Protektahan ang main branch sa panig ng forge, para ang token ng agent ay hindi makapag-push dito at hindi makapag-force-push kahit saan. Ang commit history ay nagsisilbi ring audit log ng kung ano ang nangyari habang ikaw ay natutulog, na mas mahalaga kaysa sa anumang dami ng terminal scrollback.

Ang network ay bahagi ng blast radius

Ang isang agent ay kayang magpatakbo ng curl. Ang pangungusap na iyon ang buong problema sa egress: kung ano ang kayang basahin ng agent, kaya din nitong ipadala sa kung saan, at ang isang prompt-injected agent ay maaaring gawin ito. Ang isang simpleng unprivileged user ay hindi ito nililimitahan sa anumang paraan, dahil ang sinumang user ay kayang maabot ang anumang kayang maabot ng server. Ang sandbox ay nililimitahan ito sa pamamagitan ng domain gamit ang proxy nito. Ang isang container ay maaaring maglimita nito gamit ang sarili nitong mga firewall rules. Ang isang dedicated VPS ay nililimitahan ang lahat ng pwedeng i-leak sa simula pa lang, na siyang pinakamatatag na sagot sa tatlo.

Huwag subukang lutasin ang egress gamit ang ufw lamang. Pinapayagan ng ufw ang lahat ng outgoing traffic sa default, at ang pagsusulat ng outbound rules na pinapayagan pa rin ang apt, npm, git, at ang Claude API ay isang mahirap na trabaho na tahimik na nasisira. Pumili sa halip ng boundary sa sandbox, container, o machine level, kung saan ang isang domain allow list o isang bare machine ay malinis na gumagawa ng parehong trabaho.

Kung bumubuo ka ng sarili mong agent gamit ang API sa halip na magpatakbo ng Claude Code, ang parehong pag-iisip ay applicable. Ang Pagbuo ng isang AI agent gamit ang Claude sa isang VPS ay tinatalakay ang landas na iyon, at ang agent nito ay karapat-dapat sa parehong dedicated user, parehong scoped tokens, at parehong disposable box.

Patigasin muna ang machine

Anumang rung ang piliin mo, ang machine mismo ay kailangan pa rin ng mga basic bago lumipat ang agent: SSH keys lamang, walang root login, isang default-deny firewall, at automatic security updates. I-generate ang iyong checklist dito at gawin ito nang isang beses:

FAQ

Ligtas bang gamitin ang --dangerously-skip-permissions sa isang server?

Hindi sa sarili nito. Inaalis ng flag na ito ang bawat approval prompt, kaya ang unang maling command ay tatakbo sa sandaling i-produce ito ng model. Nagiging katanggap-tanggap na trade-off ito kapag ang blast radius ay kontrolado: isang dedicated unprivileged user sa pinakamababa, at para sa tunay na unattended work, isang container o isang disposable VPS na may hawak na isang project at isang scoped token. Huwag na huwag itong gagamitin sa isang machine na may hawak na production credentials o data na hindi mo kayang mawala.

May sandbox ba ang Claude Code?

Oo. Ang Claude Code ay may built-in sandbox para sa mga shell command, na binubuksan gamit ang /sandbox command. Gumagamit ito ng bubblewrap sa Linux at Seatbelt sa macOS, nililimitahan ang mga isinusulat sa project directory, at i-ro-route ang network access sa pamamagitan ng isang proxy na nagpapahintulot lamang sa mga aprubadong domain. Ang auto-allow mode nito ay nagpapatakbo ng mga sandboxed command nang walang mga prompt, kaya binabawasan nito ang mga abala gaya ng ginagawa ng skip flag habang pinapanatili ang isang OS-enforced boundary. Hindi ito isang kumpletong isolation boundary, kaya itambal ito sa isang dedicated user o isang dedicated machine para sa mga unattended runs.

Bakit tumatangging tumakbo ang skip flag bilang root?

Dahil ang root na walang permission prompts ay maaaring magbago ng anumang file at anumang service sa system, bina-block ng Claude Code ang --dangerously-skip-permissions kapag ito ay tumatakbo bilang root o sa ilalim ng sudo sa Linux at macOS. Ang solusyon ay hindi ang pakikipaglaban sa check. Gumawa ng unprivileged user para sa agent at patakbuhin ito doon; ang account boundary na iyon ang una at pinakamurang layer ng containment.

Kaya bang basahin ng Claude Code ang aking mga SSH keys at .env files?

Kaya nitong basahin ang anumang kayang basahin ng user kung saan ito tumatakbo, at maging ang default policy ng sandbox ay pinapayagan ang pagbabasa ng mga credential paths hanggang sa i-deny mo ang mga ito. Kaya patakbuhin ang agent bilang sarili nitong user, panatilihin ang iyong sariling home directory sa mode 750 o mas mahigpit pa, i-deny ang mga credential paths sa sandbox settings, at panatilihing malayo sa machine ang lahat ng production secrets. Ang isang secret na hindi kailanman nasa machine ay hindi mababasa o ma-le-leak.

Ano ang pinakaligtas na paraan para patakbuhin ang Claude Code nang unattended?

Isang murang dedicated VPS na ginagamit lamang para sa agent work: pinatigas (hardened) sa loob ng sampung minuto, naka-snapshot nang malinis, tumatakbo ang Claude Code sa ilalim ng isang unprivileged user na may naka-on na sandbox, isang mode-600 na file na may hawak ng API key, isang per-repository deploy key, at lahat ng trabaho ay nasa mga branch na iyong i-re-review bago i-merge. Kapag nagkamali ang isang run, i-re-revoke mo ang isang token at i-restore ang snapshot, at wala nang ibang pagmamay-ari ka na maaapektuhan.