Cara Jalankan Claude Code Dengan Selamat Pada Pelayan

Maksud menjalankan Claude Code dengan selamat pada pelayan

Untuk menjalankan Claude Code dengan selamat pada pelayan, pastikan gesaan kebenaran (permission prompts) diaktifkan, jalankannya sebagai pengguna tanpa keistimewaan (unprivileged user) yang khusus, dan berikan batasan sebenar untuk tugasan tanpa pengawasan dan bukannya sekadar kepercayaan: gunakan sandbox terbina dalam, kontena, atau VPS pakai buang yang tidak mengandungi sebarang data penting. Flag --dangerously-skip-permissions membuang langkah kelulusan antara model dan shell anda. Pertukaran ini mungkin munasabah untuk kerja tanpa pengawasan, tetapi hanya di dalam batasan yang mengehadkan capaian satu arahan yang berniat jahat. Panduan ini menjelaskan perkara yang sebenarnya diubah oleh flag tersebut, dan cara membina batasan itu melalui tahap pengasingan yang semakin meningkat.

Apa yang boleh dilakukan oleh Claude Code pada pelayan anda

Claude Code ialah ejen pengekodan yang berjalan dalam terminal anda. Ia membaca fail, menulis fail, dan menjalankan arahan shell sebagai pengguna yang memulakannya. Itulah nilai keseluruhan alat ini: ia boleh mengklon repositori, menyunting kod, menjalankan ujian, membaca kegagalan, dan membaiki kod dalam satu gelung, tanpa anda perlu menaip setiap arahan. Jika anda belum menyediakannya pada pelayan, menjalankan Claude Code pada VPS dengan tmux merangkumi pemasangan dan pengendalian sesi. Halaman ini merangkumi kuasa yang anda berikan kepadanya sebaik sahaja ia berada di sana.

Risikonya adalah ayat yang sama dibaca buat kali kedua. Proses yang menjalankan arahan shell sebagai pengguna anda boleh melakukan apa sahaja yang boleh dilakukan oleh pengguna anda. Ia boleh membaca ~/.ssh/id_ed25519, ~/.aws/credentials, dan setiap fail .env yang boleh dibuka oleh pengguna anda. Ia boleh menjalankan curl dan menghantar data ke mana-mana hos yang boleh dicapai oleh pelayan. Ia boleh menjalankan git push --force. Ejen tersebut tidak mempunyai motifnya sendiri. Bahayanya ialah tugas yang tidak berjalan lancar, atau teks yang dibacanya semasa bekerja mengandungi arahan yang ditulis oleh orang lain: halaman web yang diambilnya, atau komen dalam isu yang diminta untuk dibaikinya. Kes kedua itu dipanggil suntikan prompt (prompt injection), dan itulah sebabnya "model ini biasanya munasabah" bukanlah satu pelan keselamatan. Arahan juga boleh datang dari sumber yang lebih dekat, kerana dua sesi Claude Code pada kotak yang sama boleh menghantar teks antara satu sama lain, dan mesej daripada sesi saudara hanyalah teks tambahan yang dibaca oleh ejen penerima. Anda perlu merancang untuk pelaksanaan yang buruk, bukan yang biasa.

Sistem kebenaran dalam bahasa mudah

Secara lalai, Claude Code meminta pengesahan sebelum melakukan sebarang tindakan. Membaca fail di dalam projek dilakukan secara senyap, namun menyunting fail atau menjalankan arahan shell akan memaparkan suntingan atau arahan tersebut terlebih dahulu dan menunggu jawapan ya daripada anda. Anda boleh meluluskan satu tindakan, atau meluluskan jenis tindakan tersebut untuk sepanjang sesi. Kelulusan ini terhad kepada sesi semasa: apabila anda keluar daripada CLI, sesi seterusnya akan bermula dengan berhati-hati semula. Bagi peraturan yang ingin dikekalkan, fail tetapan menyimpan senarai kebenaran (allow), permintaan (ask), dan sekatan (deny) yang kekal. Contohnya: benarkan git status, minta pengesahan pada git push, sekat bacaan .env. Peraturan sekatan sentiasa diutamakan. Garis dasar ini akan berubah, memandangkan mod automatik akan menjadi lalai pada 14 Ogos 2026, jadi adalah penting untuk mengetahui apa yang sebenarnya dibenarkan oleh setiap mod kebenaran sebelum anda menentukan mod mana yang harus dijalankan pada pelayan yang tidak dapat anda pantau.

Reka bentuk ini mengandaikan terdapat manusia yang memantau terminal, dan ini benar bagi komputer riba. Pada pelayan, tujuannya selalunya adalah kerana tiada sesiapa yang memantau. Anda memulakan tugasan yang panjang di dalam tmux dan pergi tidur, dan ejen yang berhenti untuk bertanya soalan pada pukul 2 pagi tidak akan membuat sebarang kemajuan sehingga pagi. Jeda ini merugikan wang dan masa, kerana sesi Claude Code yang melahu akan kehilangan cache prompt yang sedia ada dan pusingan seterusnya perlu membayar kos untuk membina semula cache tersebut. Itulah sebab sebenar mengapa pengguna menggunakan flag skip pada pelayan, dan masalah yang diselesaikannya adalah nyata. Selebih panduan ini adalah mengenai cara menyelesaikannya tanpa mengabaikan setiap langkah keselamatan.

Perubahan yang dilakukan oleh --dangerously-skip-permissions

claude --dangerously-skip-permissions mematikan langkah kelulusan. Suntingan dilakukan tanpa sebarang gesaan. Perintah shell dijalankan tanpa sebarang gesaan. Semakan laluan terlindung yang biasanya mengawal lokasi sensitif juga dilangkau. Peraturan penafian eksplisit anda masih terpakai, dan beberapa tindakan ekstrem masih akan terhenti untuk meminta pengesahan, tetapi ringkasan kerjanya mudah: apa sahaja yang diputuskan oleh model untuk dijalankan, akan terus dijalankan.

Dua fakta mengenai flag ini penting pada pelayan. Pertama, ia disekat apabila Claude Code dijalankan sebagai root atau di bawah sudo pada Linux dan macOS, kerana root tanpa gesaan boleh mengubah mana-mana fail atau servis pada mesin tersebut. Ejen tersebut memerlukan akaun tanpa keistimewaan (unprivileged) sendiri, dan flag ini menguatkuasakan perkara itu. Kedua, flag ini tidak mengubah tingkah laku model dalam apa jua cara. Ia hanya mengeluarkan manusia daripada gelung (loop) dan tidak mengubah perkara lain, jadi setiap kesilapan yang sepatutnya dapat dikesan oleh gesaan kini akan terus dilaksanakan.

Oleh itu, inilah pengiraan yang jujur. Jika anda melangkau kebenaran (permissions), persoalan keselamatan berubah daripada "adakah ejen akan melakukan sesuatu yang buruk" kepada "sejauh mana kerosakan yang boleh dilakukan oleh satu tindakan buruk". Anda berhenti cuba mengawal setiap keputusan dan mula mengawal radius letupan (blast radius). Pengekangan (containment) adalah jawapannya, dan ia datang dalam beberapa peringkat.

Sandbox terbina dalam Claude Code

Sebelum melangkah ke tahap seterusnya, perlu diketahui bahawa Claude Code kini menyertakan sandbox peringkat OS untuk arahan yang dijalankannya, dan ia menghapuskan kebanyakan sebab pengguna menggunakan flag skip. Pada Linux, ia menggunakan bubblewrap untuk pengasingan sistem fail, serta socat untuk menghalakan trafik rangkaian melalui proksi. Di dalam sandbox, sesuatu arahan hanya boleh menulis ke direktori projek dan direktori sementara sesi, dan ia hanya boleh mencapai rangkaian melalui proksi yang menyemak setiap domain terhadap senarai yang dibenarkan. Kali pertama sesuatu arahan memerlukan domain baharu, Claude Code akan meminta kebenaran anda.

Aktifkannya dengan arahan /sandbox di dalam sesi. Pada Ubuntu dan Debian, pasang dua pakej yang diperlukan terlebih dahulu:

sudo apt install bubblewrap socat

Pada Ubuntu 24.04 dan versi terbaharu, polisi AppArmor lalai menghalang bubblewrap daripada mencipta ruang nama pengguna (user namespaces) yang diperlukannya. Panel sandbox akan memberitahu anda apabila sesuatu komponen tiada, dan dokumentasi sandboxing Claude Code mengandungi profil AppArmor ringkas yang membetulkannya.

Sandbox ini mempunyai mod auto-allow: arahan yang disandboxkan berjalan tanpa sebarang gesaan, kerana sempadan yang dikuatkuasakan kini melakukan tugas yang sebelum ini dilakukan oleh gesaan tersebut. Arahan yang tidak boleh dijalankan di dalam sandbox akan kembali kepada aliran kebenaran biasa, jadi tindakan yang benar-benar luar biasa masih akan meminta kebenaran. Bagi kebanyakan aliran kerja pelayan, ini adalah pengganti yang tepat untuk flag skip, kerana anda akan menerima jauh lebih sedikit soalan dengan sempadan yang dikuatkuasakan oleh OS berbanding tiada langsung.

Bersikap jujur tentang hadnya. Secara lalai, arahan yang disandboxkan masih boleh membaca kebanyakan sistem fail, termasuk fail kelayakan, melainkan anda menafikan laluan tersebut; tetapan sandbox.credentials wujud khusus untuk tujuan itu. Proksi rangkaian menyemak nama domain dan tidak memeriksa trafik itu sendiri, jadi kebenaran yang luas seperti github.com masih memberi ruang untuk memindahkan data keluar. Docker tidak berfungsi di dalamnya. Sandbox ini meningkatkan tahap keselamatan dengan ketara. Ia bukanlah sempadan pengasingan yang lengkap, itulah sebabnya tahap-tahap di bawah masih penting.

Tangga pengasingan

Tiga tahap, mengikut urutan pengasingan yang semakin meningkat. Pilih tahap terendah yang sepadan dengan apa jua yang terdapat pada pelayan tersebut.

Tahap 1: pengguna tanpa keistimewaan (unprivileged) yang khusus. Ejen tersebut mendapat akaun sendiri, direktori home sendiri, direktori projek sendiri, dan tiada akses sudo:

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

Sempadan akaun menghalang ejen daripada mengakses fail anda: kunci SSH anda dan setiap projek lain pada mesin tersebut. Ia juga membolehkan penggunaan flag skip, kerana flag tersebut enggan dijalankan sebagai root. Ini adalah prinsip yang sama seperti menjalankan setiap servis sebagai pengguna tanpa keistimewaan, yang diaplikasikan kepada ejen. Apa yang tidak dihadkan oleh tahap 1: rangkaian, dan apa sahaja pada mesin yang boleh dibaca oleh semua orang (world-readable).

Tahap 2: kontena. Anthropic menerbitkan devcontainer rujukan yang menjalankan Claude Code sebagai pengguna bukan root, dengan peraturan firewall yang mengehadkan hos yang boleh dicapai oleh ejen, dan kontena yang anda bina sendiri melakukan tugas yang sama. Sistem fail mengecil kepada volum yang anda lekapkan (mount), dan trafik keluar (egress) mengecil kepada apa yang dibenarkan oleh peraturan kontena. Ini adalah tahap pertengahan yang sesuai apabila pelayan menempatkan servis lain yang penting bagi anda. Hadnya ialah kontena berkongsi kernel hos, dan satu lekapan yang cuai akan membatalkan sempadan tersebut; berikan kontena /var/run/docker.sock dan ia boleh mencapai keseluruhan hos.

Tahap 3: VPS khusus. Tahap paling kuat adalah yang paling mudah: berikan ejen sebuah mesin keseluruhan yang tidak mengandungi apa-apa yang penting bagi anda. VPS kecil hanya menelan kos beberapa dolar sebulan. Sediakan ia dengan buku panduan sepuluh minit pertama pada VPS baharu, ambil snapshot keadaan bersih, dan biarkan ejen bekerja. Tiada apa-apa lagi yang tinggal di sana. Tiada kunci SSH peribadi, hanya kunci deploy yang dihadkan kepada satu repositori sahaja. Tiada kelayakan awan, tiada data pengeluaran. Apabila sesuatu tugasan tidak berjalan lancar, atau apabila anda hanya mahukan keadaan asal yang bersih, pulihkan snapshot atau musnahkan dan bina semula mesin tersebut dalam beberapa minit. Jejari letupan (blast radius) adalah kos sewa tersebut. Ini adalah persediaan di mana --dangerously-skip-permissions tidak lagi menakutkan, kerana hasil realistik yang paling buruk hanyalah pelayan yang dibina semula dan satu token yang dibatalkan.

Tahap-tahap ini boleh disusun. Ejen yang disandbox, berjalan sebagai pengguna tanpa keistimewaan, pada VPS yang boleh dibuang, hampir tidak menelan kos tambahan dan menjadikan kisah kegagalan sesuatu yang membosankan. Membosankan adalah matlamatnya.

Melindungi kelayakan

Peraturan yang paling utama: pengguna ejen tidak boleh membaca rahsia milik entiti lain.

Berikan kunci API hanya kepada ejen dan tiada yang lain. Letakkannya dalam fail yang dimiliki oleh pengguna ejen dengan mod 600, dan muatkannya apabila shell bermula:

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

Kemudian, tutup akses dari arah lain. Pada Debian dan Ubuntu, direktori rumah sering kali dicipta supaya boleh dibaca oleh setiap pengguna dalam sistem, jadi ketatkan direktori anda: chmod 750 /home/youruser. Semak dengan ls -ld /home/* dan betulkan sebarang fail yang boleh disenaraikan oleh akaun ejen.

Hadkan skop setiap token. Token GitHub yang terperinci dan dihadkan kepada satu repositori, atau kunci deploy bagi setiap repositori, bermakna kelayakan yang bocor hanya menjejaskan satu projek dan bukan keseluruhan akaun anda. Jika anda menggunakan sandbox, tambahkan tetapan kelayakannya supaya ~/.ssh dan ~/.aws dinafikan walaupun untuk bacaan. Selain itu, jauhkan kelayakan pengeluaran (production) daripada pelayan tersebut sepenuhnya, kerana ejen tidak boleh membocorkan rahsia yang tidak pernah ada di situ. Jika rahsia tersebut disimpan dalam pengurus kata laluan yang dihoskan sendiri, simpan ia pada pelayan yang berbeza daripada ejen dan lakukan semakan berasingan, kerana kelemahan Vaultwarden terletak pada token admin dan fail sandaran dan bukannya pada vault yang disulitkan itu sendiri.

Git sebagai jaring keselamatan

Setiap perubahan yang dilakukan oleh ejen harus boleh disemak dan dipulihkan, dan git memberikan kedua-dua keupayaan ini secara percuma jika ejen bekerja pada cawangan (branch):

git switch -c agent/refactor-auth

Semak pelaksanaan tersebut selepas itu dengan git diff main...agent/refactor-auth, gabungkan (merge) apa yang baik, dan padamkan cawangan jika pelaksanaan tersebut tidak membuahkan hasil. Pelaksanaan yang menyentuh tiga fail adalah jauh lebih mudah dibaca semasa sarapan berbanding pelaksanaan yang menulis semula separuh modul, yang merupakan kes praktikal bagi kemahiran yang mengehadkan ejen kepada perubahan terkecil yang berfungsi. Lindungi cawangan utama (main branch) pada bahagian forge, supaya token ejen tidak boleh melakukan push ke cawangan tersebut dan tidak boleh melakukan force-push di mana-mana. Sejarah commit berfungsi sebagai log audit tentang apa yang berlaku semasa anda tidur, yang lebih bernilai daripada mana-mana jumlah tatalan terminal (terminal scrollback).

Rangkaian adalah sebahagian daripada radius letupan

Satu ejen boleh menjalankan curl. Ayat tersebut merangkumi keseluruhan masalah egress: apa sahaja yang boleh dibaca oleh ejen, ia juga boleh dihantar ke suatu tempat, dan ejen yang terdedah kepada prompt injection mungkin melakukannya. Pengguna biasa tanpa keistimewaan tidak mengehadkan perkara ini sama sekali, kerana mana-mana pengguna boleh mencapai apa sahaja yang boleh dicapai oleh pelayan. Sandbox mengehadkan perkara ini mengikut domain melalui proksinya. Kontena boleh mengehadkannya dengan peraturan firewallnya sendiri. VPS khusus mengehadkan apa yang boleh dibocorkan sejak awal lagi, yang merupakan jawapan paling mantap antara ketiga-tiganya.

Jangan cuba menyelesaikan masalah egress dengan ufw sahaja. ufw membenarkan semua trafik keluar secara lalai, dan menulis peraturan keluar yang masih membenarkan apt, npm, git, dan Claude API adalah kerja yang rumit dan mudah gagal tanpa disedari. Sebaliknya, pilih sempadan di peringkat sandbox, kontena, atau mesin, di mana senarai kebenaran domain atau mesin kosong melakukan tugas yang sama dengan lebih kemas.

Jika anda membina ejen anda sendiri menggunakan API dan bukannya menjalankan Claude Code, pemikiran yang sama terpakai tanpa perubahan. Membina ejen AI dengan Claude pada VPS merangkumi laluan tersebut, dan ejennya memerlukan pengguna khusus yang sama, token dengan skop yang sama, dan kotak pakai buang yang sama.

Keraskan pelayan terlebih dahulu

Tidak kira tahap mana yang anda pilih, mesin tersebut tetap memerlukan langkah asas sebelum ejen dipasang: hanya gunakan SSH keys, tiada log masuk root, firewall dengan polisi default-deny, dan kemas kini keselamatan automatik. Jana senarai semak anda di sini dan selesaikan satu per satu:

FAQ

Adakah --dangerously-skip-permissions selamat digunakan pada pelayan?

Tidak secara sendirinya. Flag ini membuang setiap gesaan kelulusan, jadi arahan buruk pertama akan terus berjalan sebaik sahaja model menghasilkannya. Ia menjadi pertukaran yang boleh dipertahankan apabila radius impak dikawal: sekurang-kurangnya menggunakan pengguna tanpa keistimewaan (unprivileged user) yang khusus, dan untuk kerja yang benar-benar tanpa pengawasan, gunakan kontena atau VPS pakai buang yang hanya memegang satu projek dan satu token berlingkup. Jangan sekali-kali menggunakannya pada mesin yang menyimpan kelayakan pengeluaran (production credentials) atau data yang anda tidak boleh kehilangan.

Adakah Claude Code mempunyai sandbox?

Ya. Claude Code menyertakan sandbox terbina dalam untuk arahan shell, yang dibuka dengan arahan /sandbox. Ia menggunakan bubblewrap pada Linux dan Seatbelt pada macOS, mengehadkan penulisan kepada direktori projek, dan menghalakan akses rangkaian melalui proksi yang hanya membenarkan domain yang diluluskan. Mod auto-allow miliknya menjalankan arahan dalam sandbox tanpa gesaan, jadi ia mengurangkan gangguan seperti yang dilakukan oleh flag skip sambil mengekalkan sempadan yang dikuatkuasakan oleh OS. Ia bukan sempadan pengasingan yang lengkap, jadi gandingkan ia dengan pengguna khusus atau mesin khusus untuk tugasan tanpa pengawasan.

Mengapa flag skip enggan berjalan sebagai root?

Kerana root tanpa gesaan kebenaran boleh mengubah suai mana-mana fail dan mana-mana servis pada sistem, Claude Code menyekat --dangerously-skip-permissions apabila ia berjalan sebagai root atau di bawah sudo pada Linux dan macOS. Penyelesaiannya bukan dengan melawan semakan tersebut. Cipta pengguna tanpa keistimewaan untuk ejen tersebut dan jalankannya di sana; sempadan akaun itu adalah lapisan kawalan pertama dan paling murah.

Bolehkah Claude Code membaca kunci SSH dan fail .env saya?

Ia boleh membaca apa sahaja yang boleh dibaca oleh pengguna yang menjalankannya, malah polisi lalai sandbox membenarkan bacaan laluan kelayakan sehingga anda menafikannya. Jadi, jalankan ejen sebagai penggunanya sendiri, pastikan direktori home anda berada pada mod 750 atau lebih ketat, nafikan laluan kelayakan dalam tetapan sandbox, dan jauhkan rahsia pengeluaran (production secrets) daripada mesin tersebut sepenuhnya. Rahsia yang tidak pernah disimpan dalam kotak tidak boleh dibaca atau dibocorkan.

Apakah cara paling selamat untuk menjalankan Claude Code tanpa pengawasan?

VPS khusus yang murah yang hanya digunakan untuk kerja ejen: dikukuhkan dalam sepuluh minit, diambil snapshot dalam keadaan bersih, menjalankan Claude Code di bawah pengguna tanpa keistimewaan dengan sandbox dihidupkan, fail mod-600 yang menyimpan kunci API, kunci deploy bagi setiap repositori, dan semua kerja dilakukan pada cawangan (branches) yang anda semak sebelum menggabungkannya (merging). Jika sesuatu tugasan gagal, anda hanya perlu membatalkan satu token dan memulihkan snapshot, dan tiada aset lain milik anda yang terjejas.