Paano Ligtas Patakbuhin ang Claude Code sa Server

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

Para ligtas na patakbuhin ang Claude Code sa server, panatilihing naka-enable ang mga permission prompt nito, patakbuhin ito bilang dedicated unprivileged user, at bigyan ng tunay na boundary ang mga unattended run sa halip na umasa sa trust: ang built-in sandbox, isang container, o isang disposable VPS na walang mahahalagang data. Tinatanggal ng --dangerously-skip-permissions flag ang approval step sa pagitan ng model at ng shell mo. Maaaring makatwiran ang trade-off na ito para sa unattended work, pero dapat lamang itong gamitin sa loob ng boundary na naglilimita sa maaabot ng isang maling command. Ipinapaliwanag ng guide na ito kung ano talaga ang binabago ng flag at kung paano bumuo ng boundary na may pataas nang pataas na antas ng isolation.

Mga Kayang Gawin ng Claude Code sa Iyong Box

Ang Claude Code ay isang coding agent na tumatakbo sa iyong terminal. Nagbabasa ito ng mga file, nagsusulat ng mga file, at nagpapatakbo ng shell commands bilang user na nag-start dito. Iyan ang buong halaga ng tool: kaya nitong mag-clone ng repository, mag-edit ng code, magpatakbo ng tests, basahin ang failure, at ayusin ang code nang paulit-ulit, nang hindi mo kailangang i-type ang bawat command. Kung hindi mo pa ito na-set up sa server, saklaw ng pagpapatakbo ng Claude Code sa VPS gamit ang tmux ang pag-install at pamamahala ng session. Sinasaklaw ng page na ito ang kapangyarihang ibinibigay mo rito kapag naka-set up na ito.

Pareho pa rin ang panganib kapag binasa nang ikalawang beses ang pangungusap na ito. Ang process na nagpapatakbo ng shell commands bilang iyong user ay kayang gawin ang anumang kaya ng iyong user. Kaya nitong basahin ang ~/.ssh/id_ed25519, ~/.aws/credentials, at bawat .env file na kayang buksan ng iyong user. Kaya nitong patakbuhin ang curl at magpadala ng data sa anumang host na kayang maabot ng server. Kaya nitong patakbuhin ang git push --force. Walang sariling motibo ang agent. Ang panganib ay maaaring magkamali ang isang task, o maaaring may tekstong nabasa nito habang nagtatrabaho na naglalaman ng mga instruction mula sa ibang tao: isang web page na kinuha nito, o isang comment sa isang issue na ipinagawa rito. Ang ikalawang sitwasyon ay tinatawag na prompt injection. Ito ang dahilan kung bakit hindi sapat na security plan ang paniniwalang “karaniwang sensible ang model.” Maaari ring manggaling ang mga instruction sa mas malapit na pinagmumulan, dahil maaaring magpadalhan ng text ang dalawang Claude Code session sa iisang box, at ang message mula sa sibling session ay text lang din na binabasa ng tumatanggap na agent. Nagpaplano ka para sa mapanganib na run, hindi para sa karaniwang run.

Ang permission system sa payak na paliwanag

Bilang default, nagtatanong muna ang Claude Code bago kumilos. Tahimik na binabasa ang mga file sa loob ng project, pero kapag mag-e-edit ng file o magpapatakbo ng shell command, ipinapakita muna ang eksaktong edit o command at naghihintay ng approval. Maaari mong aprubahan ang isang action, o aprubahan ang ganoong uri ng action para sa natitirang bahagi ng session. Saklaw lang ng session ang mga approval na ito: kapag isinara mo ang CLI, maingat na ulit magsisimula ang susunod na session. Para sa mga rule na gusto mong panatilihin, naglalaman ang settings file ng persistent allow, ask, at deny lists. Halimbawa: i-allow ang git status, mag-ask para sa git push, at i-deny ang mga read ng .env. Laging nangingibabaw ang deny rules. Nagbabago rin ang baseline na ito, dahil magiging default ang auto mode sa 14 August 2026. Kaya mahalagang malaman kung ano talaga ang pinapayagan ng bawat permission mode bago ka magpasya kung alin ang dapat patakbuhin sa server na hindi mo mababantayan.

Ipinapalagay ng design na may taong nagbabantay sa terminal. Totoo ito sa laptop. Sa server, madalas ay walang nagbabantay. Nagsisimula ka ng matagal na task sa loob ng tmux at natutulog, pero kapag huminto ang agent para magtanong nang 2 a.m., walang progreso hanggang umaga. May gastos sa oras at pera ang paghinto, dahil nawawala sa idle na Claude Code session ang warm prompt cache nito at kailangang bayaran sa susunod na turn ang pagbuo nito muli. Ito ang tapat na dahilan kung bakit ginagamit ng mga tao ang skip flag sa mga server. Totoo ang problemang nalulutas nito. Tungkol ang natitirang bahagi ng guide na ito sa paglutas nito nang hindi inaalis ang lahat ng guardrail.

Mga binabago ng --dangerously-skip-permissions

claude --dangerously-skip-permissions inaalis ang approval step. Isinasagawa ang mga edit nang walang prompt. Tumatakbo rin ang mga shell command nang walang prompt. Nilalaktawan din ang mga protected-path check na karaniwang nagpoprotekta sa mga sensitibong lokasyon. Nananatiling umiiral ang iyong mga explicit deny rule, at humihinto pa rin upang magtanong ang ilang extreme action, pero simple ang buod: anumang ipasyang patakbuhin ng model ay tatakbo.

Mahalaga sa isang server ang dalawang fact tungkol sa flag na ito. Una, naka-block ito kapag tumatakbo ang Claude Code bilang root o sa ilalim ng sudo sa Linux at macOS, dahil maaaring baguhin ng root na walang prompt ang anumang file o service sa machine. Kailangan din ng agent ng sarili nitong unprivileged account, at ipinapatupad iyon ng flag. Ikalawa, hindi binabago ng flag ang behaviour ng model sa anumang paraan. Inaalis nito ang tao sa proseso at wala nang ibang binabago, kaya ang bawat pagkakamaling sana ay naharang ng prompt ay maisasagawa na.

Kaya ito ang tapat na pagsusuri. Kapag nilaktawan mo ang permissions, nagbabago ang security question mula sa “may gagawin bang masama ang agent” tungo sa “gaano kalaking damage ang maaaring idulot ng isang maling action”. Hindi mo na sinusubukang kontrolin ang bawat decision. Sa halip, kinokontrol mo ang blast radius. Containment ang sagot, at may mga antas ito.

Ang built-in na Claude Code sandbox

Bago ang mga rung, alamin na may OS-level sandbox na ngayon ang Claude Code para sa mga command na pinapatakbo nito. 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 at ng socat para i-route ang network traffic sa pamamagitan ng proxy. Sa loob ng sandbox, maaari lamang magsulat ang isang command sa project directory at session temp directory. Maaari lamang itong kumonekta sa network sa pamamagitan ng proxy na tumitingin sa bawat domain laban sa allow list. Sa unang pagkakataong kailangan ng command ng bagong domain, tatanungin ka ng Claude Code.

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

sudo apt install bubblewrap socat

Sa Ubuntu 24.04 at mas bagong version, pinipigilan ng default AppArmor policy ang bubblewrap na lumikha ng user namespaces na kailangan nito. Ipapaalam sa iyo ng sandbox panel kapag may kulang. Makikita rin sa Claude Code sandboxing documentation ang maikling AppArmor profile na nag-aayos nito.

May auto-allow mode ang sandbox. Tumatakbo ang mga sandboxed command nang walang prompt dahil ang enforced boundary na ang gumagawa ng dating tungkulin ng prompt. Ang mga command na hindi maaaring tumakbo sa loob ng sandbox ay bumabalik sa normal permission flow. Kaya nagtatanong pa rin ang mga talagang hindi pangkaraniwang action. Para sa karamihan ng server workflow, ito ang tamang kapalit ng skip flag dahil mas kaunti ang tanong kapag may OS-enforced boundary kaysa kapag wala nito.

Maging tapat sa mga limitasyon nito. Bilang default, mababasa pa rin ng isang sandboxed command ang karamihan sa filesystem, kabilang ang mga credential file, maliban kung i-deny mo ang mga path na iyon. Para mismo rito ang sandbox.credentials setting. Sinusuri ng network proxy ang mga domain name at hindi nito ini-inspect ang traffic mismo. Kaya ang malawak na allow gaya ng github.com ay nagbibigay pa rin ng pagkakataong maglabas ng data. Hindi gumagana ang Docker sa loob nito. Malaki ang itinaas ng baseline security na ibinibigay ng sandbox. Hindi ito kumpletong isolation boundary, kaya mahalaga pa rin ang mga rung sa ibaba.

Ang containment ladder

Tatlong antas ito, mula sa mas mababang isolation hanggang sa mas mataas. Piliin ang pinakamababang antas na angkop sa iba pang tumatakbo sa server.

Antas 1: isang dedicated unprivileged user. Bibigyan ang agent ng sarili nitong account, home directory, project directory, at walang sudo:

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

Pinapanatili ng account boundary na hindi ma-access ng agent ang iyong mga file: ang iyong SSH keys at lahat ng iba pang project sa machine. Ginagawa rin nitong magagamit ang skip flag, dahil tumatanggi itong tumakbo bilang root. Ito ang parehong prinsipyo ng pagpapatakbo ng bawat service bilang unprivileged user, na inilapat sa isang agent. Ang hindi nalilimitahan ng antas 1: ang network at anumang world-readable sa machine.

Antas 2: isang container. Naglalabas ang Anthropic ng reference devcontainer na nagpapatakbo ng Claude Code bilang non-root user, na may firewall rules na naglilimita sa mga host na maaaring maabot ng agent. Pareho rin ang ginagawa ng container na ikaw mismo ang mag-build. Nalilimitahan ang filesystem sa mga volume na mina-mount mo, at nalilimitahan ang egress sa pinapahintulutan ng rules ng container. Ito ang tamang gitnang antas kapag may iba pang serbisyong mahalaga sa server. Limitasyon nito na magkakapareho ang host kernel ng mga container, at maaaring mawala ang boundary dahil sa isang maling mount; kapag ibinigay sa container ang /var/run/docker.sock, maaabot nito ang buong host.

Antas 3: isang dedicated VPS. Pinakamalakas ngunit pinakadirekta ang antas na ito: bigyan ang agent ng buong machine na walang ibang laman na mahalaga sa iyo. Ilang dollar bawat buwan ang halaga ng maliit na VPS. I-set up ito gamit ang runbook para sa unang sampung minuto sa bagong VPS, gumawa ng snapshot ng malinis na state, at hayaang magtrabaho ang agent. Walang ibang tumatakbo roon. Walang personal SSH key; deploy key lamang na limitado sa isang repository. Walang cloud credentials at walang production data. Kapag nagkaproblema ang isang run, o kapag gusto mo lang ng malinis na state, i-restore ang snapshot o i-destroy at i-rebuild ang machine sa loob ng ilang minuto. Ang blast radius ay ang halaga ng renta. Sa setup na ito, hindi na nakakatakot ang --dangerously-skip-permissions, dahil ang pinakamasamang makatotohanang resulta ay isang server na kailangang i-rebuild at isang token na kailangang i-revoke.

Nagsasama-sama ang mga antas. Ang sandboxed agent na tumatakbo bilang unprivileged user sa disposable VPS ay halos walang dagdag na gastos at ginagawang simple ang mga posibleng failure. Iyan ang layunin.

Protektahan ang mga credential

Ito ang pangunahing panuntunan na sumusuporta sa lahat ng iba pa: hindi dapat mabasa ng user ng agent ang mga secret na pagmamay-ari ng ibang account o serbisyo.

Ibigay ang API key sa agent lamang. Ilagay ito sa file na pagmamay-ari ng user ng agent at may mode na 600, at i-load ito kapag nagsisimula ang 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, higpitan ang access sa kabilang direksiyon. Sa Debian at Ubuntu, karaniwang readable ng bawat user sa server ang home directories, kaya higpitan ang sarili mong home directory: chmod 750 /home/youruser. Suriin ito gamit ang ls -ld /home/* at ayusin ang anumang directory na maaaring ilista ng account ng agent.

Limitahan ang saklaw ng bawat token. Ang fine-grained GitHub token na limitado sa isang repository, o isang deploy key para sa bawat repository, ay nangangahulugang isang project lang ang maaapektuhan kapag na-leak ang credential, hindi ang buong account mo. Kung ginagamit mo ang sandbox, idagdag ang credential settings nito upang ma-deny ang ~/.ssh at ~/.aws kahit para sa read operations. Huwag ding ilagay sa server ang production credentials, dahil hindi maaaring ma-leak ng agent ang isang secret na wala naman doon. Kung nasa self-hosted password manager ang mga secret na iyon, ilagay ito sa ibang server mula sa agent at isailalim ito sa hiwalay na review, dahil ang mahihinang bahagi ng Vaultwarden ay ang admin token at backup file, hindi ang encrypted vault mismo.

Ang Git ang safety net

Dapat nasusuri at naibabalik ang bawat pagbabagong ginagawa ng agent. Makukuha mo ang dalawang ito nang walang dagdag na configuration kung gagamit ang agent ng branch:

git switch -c agent/refactor-auth

Suriin ang naging run gamit ang git diff main...agent/refactor-auth. I-merge ang mga pagbabagong maayos at i-delete ang branch kung walang naging resulta ang run. Mas madaling basahin habang nag-aalmusal ang run na tatlong file lang ang binago kaysa sa run na muling sumulat sa kalahati ng module. Ito ang praktikal na dahilan para gumamit ng skill na naglilimita sa agent sa pinakamaliit na gumaganang pagbabago. Protektahan ang main branch sa forge para hindi ito ma-push ng token ng agent at hindi rin ito makapag-force-push saanman. Ang commit history ay nagsisilbi ring audit log ng mga nangyari habang natutulog ka. Mas mahalaga ito kaysa sa anumang dami ng terminal scrollback.

Bahagi ng blast radius ang network

Maaaring magpatakbo ang isang agent ng curl. Iyan ang buong problema sa egress: anumang mabasa ng agent ay maaari rin nitong ipadala sa ibang lugar, at maaaring gawin iyon ng agent na naapektuhan ng prompt injection. Hindi ito nalilimitahan ng isang ordinaryong unprivileged user, dahil maaaring maabot ng anumang user ang lahat ng naaabot ng server. Nililimitahan ito ng sandbox batay sa domain sa pamamagitan ng proxy nito. Maaari itong limitahan ng isang container gamit ang sarili nitong firewall rules. Nililimitahan naman ng dedicated VPS ang mismong dami ng maaaring ma-leak, kaya ito ang pinakamatibay na sagot sa tatlong opsyon.

Huwag subukang lutasin ang egress gamit ang ufw lamang. Bilang default, pinapayagan ng ufw ang lahat ng outgoing traffic, at mahirap buuin ang outbound rules na papayagan pa rin ang apt, npm, git, at Claude API. Maaari rin itong tahimik na masira. Piliin ang boundary sa antas ng sandbox, container, o machine. Sa mga antas na ito, malinis na maisasagawa ang parehong gawain gamit ang domain allow list o bare machine.

Kung gumagawa ka ng sarili mong agent gamit ang API sa halip na magpatakbo ng Claude Code, pareho pa rin ang prinsipyong ito. Sinasaklaw ng Pagbuo ng AI agent gamit ang Claude sa isang VPS ang prosesong iyon. Dapat mayroon din ang agent nito ng parehong dedicated user, parehong scoped tokens, at parehong disposable box.

Patibayin muna ang server

Anuman ang piliin mong rung, kailangan pa rin ng machine mismo ang mga pangunahing security setting bago ito lagyan ng agent: SSH keys lamang, walang root login, firewall na default-deny, at automatic security updates. Buuin dito ang checklist mo at sundin ito nang isang beses mula umpisa hanggang dulo:

FAQ

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

Hindi kung ito lamang. Tinatanggal ng flag ang bawat approval prompt, kaya tatakbo agad ang unang mapanganib na command sa sandaling mabuo ito ng model. Nagiging katanggap-tanggap lamang ang trade-off kapag limitado ang blast radius: gumamit man lang ng dedikadong unprivileged user, at para sa tunay na unattended na trabaho, gumamit ng container o disposable VPS na naglalaman ng isang project at isang scoped token. Huwag itong gamitin sa machine na naglalaman ng production credentials o data na hindi mo kayang mawala.

May sandbox ba ang Claude Code?

Oo. May built-in sandbox ang Claude Code para sa shell commands, na binubuksan gamit ang /sandbox command. Gumagamit ito ng bubblewrap sa Linux at Seatbelt sa macOS, nililimitahan ang pagsusulat sa project directory, at ipinapadaan ang network access sa isang proxy na pinapahintulutan lamang ang mga approved domain. Ang auto-allow mode nito ay nagpapatakbo ng mga sandboxed command nang walang prompt, kaya binabawasan nito ang mga interruption gaya ng skip flag habang pinananatili ang boundary na ipinapatupad ng OS. Hindi ito kumpletong isolation boundary, kaya ipares ito sa dedikadong user o dedikadong machine para sa unattended runs.

Bakit tumatangging tumakbo bilang root ang skip flag?

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

Mababasa ba ng Claude Code ang aking SSH keys at .env files?

Mababasa nito ang anumang mababasa ng user na ginagamit nito sa pagtakbo, at pinapahintulutan pa rin ng default policy ng sandbox ang pagbasa sa credential paths hangga't hindi mo ito dini-deny. Kaya patakbuhin ang agent bilang sariling user nito, panatilihin ang sarili mong home directory sa mode 750 o mas mahigpit, i-deny ang credential paths sa sandbox settings, at huwag ilagay sa machine ang production secrets. Hindi mababasa o maile-leak ang isang secret na hindi kailanman nasa box.

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

Gumamit ng murang dedikadong VPS na para lamang sa agent work: i-harden ito sa loob ng sampung minuto, gumawa ng malinis na snapshot, patakbuhin ang Claude Code sa ilalim ng unprivileged user na naka-on ang sandbox, maglagay ng API key sa isang mode-600 file, gumamit ng per-repository deploy key, at gawin ang lahat ng trabaho sa mga branch na rerebyuhin mo bago i-merge. Kung magkaproblema ang isang run, isang token lamang ang ire-revoke mo at ibabalik ang snapshot, at walang ibang pag-aari mo ang maaapektuhan.