सर्व्हरवर Claude Code सुरक्षितपणे कसे चालवावे

सर्व्हरवर Claude Code सुरक्षितपणे चालवण्याचा अर्थ

सर्व्हरवर Claude Code सुरक्षितपणे चालवण्यासाठी त्याचे permission prompts सुरू ठेवा. ते dedicated unprivileged user म्हणून चालवा. unattended runs साठी केवळ विश्वासावर अवलंबून राहू नका; त्याऐवजी built-in sandbox, container किंवा तुमच्यासाठी महत्त्वाचा कोणताही डेटा नसलेला disposable VPS वापरा. --dangerously-skip-permissions flag मुळे model आणि तुमच्या shell यांच्यामधील approval step काढून टाकला जातो. unattended कामासाठी ही तडजोड योग्य ठरू शकते. मात्र, एखाद्या चुकीच्या command ची पोहोच मर्यादित करणाऱ्या boundary च्या आतच ती वापरा. या मार्गदर्शकात हा flag प्रत्यक्षात काय बदलतो आणि वाढत्या isolation पातळ्यांमध्ये अशी boundary कशी तयार करावी हे स्पष्ट केले आहे.

तुमच्या box वर Claude Code काय करू शकते

Claude Code हा तुमच्या terminal मध्ये चालणारा coding agent आहे. तो files वाचतो, files लिहितो आणि तो सुरू करणाऱ्या user च्या अधिकारांनुसार shell commands चालवतो. या tool चे संपूर्ण मूल्य यामध्ये आहे: तो repository clone करू शकतो, code संपादित करू शकतो, tests चालवू शकतो, failure वाचू शकतो आणि प्रत्येक command तुम्ही स्वतः टाइप न करता loop मध्ये code दुरुस्त करू शकतो. तुम्ही ते अद्याप server वर सेट केले नसेल, तर tmux वापरून VPS वर Claude Code चालवणे यामध्ये installation आणि session handling दिले आहे. Claude Code उपलब्ध झाल्यानंतर तुम्ही त्याला कोणते अधिकार देता, हे या पृष्ठात स्पष्ट केले आहे.

जोखीम समजून घेण्यासाठी हेच वाक्य पुन्हा वाचा. तुमच्या user च्या अधिकारांनुसार shell commands चालवणारी process तुमचा user जे काही करू शकतो ते सर्व करू शकते. ती ~/.ssh/id_ed25519, ~/.aws/credentials आणि तुमचा user उघडू शकणाऱ्या प्रत्येक .env file ला वाचू शकते. ती curl चालवू शकते आणि server ज्या कोणत्याही host पर्यंत पोहोचू शकतो, तिथे data पाठवू शकते. ती git push --force चालवू शकते. Agent चा स्वतःचा कोणताही हेतू नसतो. धोका असा असतो की एखादे task चुकीच्या पद्धतीने पूर्ण होते किंवा काम करताना त्याने वाचलेल्या text मध्ये दुसऱ्या व्यक्तीने लिहिलेल्या instructions असतात: उदाहरणार्थ, त्याने fetch केलेले web page किंवा दुरुस्त करण्यास सांगितलेल्या issue मधील comment. या दुसऱ्या परिस्थितीला prompt injection म्हणतात. त्यामुळे "model सहसा योग्य निर्णय घेते" ही security plan ठरू शकत नाही. Instructions तुमच्या जवळच्या स्रोतांकडूनही येऊ शकतात, कारण एकाच box वर चालणाऱ्या दोन Claude Code sessions एकमेकांना text पाठवू शकतात, आणि sibling session कडून आलेला message म्हणजे receiving agent ने वाचलेला आणखी एक text असतो. सरासरी परिस्थितीचा नव्हे, तर चुकीच्या run चा विचार करून योजना करा.

परवानगी प्रणाली सोप्या भाषेत

मूळ सेटिंगमध्ये Claude Code कोणतीही कृती करण्यापूर्वी विचारते. प्रकल्पातील फाइल्स वाचणे शांतपणे होते; परंतु फाइलमध्ये बदल करणे किंवा shell command चालवणे यापूर्वी नेमका बदल किंवा command दाखवला जातो आणि तुमच्या होकाराची प्रतीक्षा केली जाते. तुम्ही एखादी कृती एकदा मंजूर करू शकता किंवा सत्राच्या उर्वरित कालावधीसाठी त्या प्रकारची कृती मंजूर करू शकता. या मंजुरी सत्रापुरत्या मर्यादित असतात: CLI बंद केल्यावर पुढील सत्र पुन्हा सावध पद्धतीने सुरू होते. कायम ठेवायच्या नियमांसाठी settings file मध्ये persistent allow, ask आणि deny lists असतात. उदाहरणार्थ: git status ला allow करा, git push वर ask करा आणि .env चे reads deny करा. deny नियमांना नेहमी प्राधान्य असते. ही मूलभूत रचना देखील बदलत आहे, कारण 14 August 2026 रोजी auto mode default होणार आहे. त्यामुळे server वर कोणता permission mode चालवायचा हे ठरवण्यापूर्वी प्रत्येक permission mode प्रत्यक्षात काय परवानगी देतो हे जाणून घेणे उपयुक्त ठरते, विशेषतः त्या server वर तुम्ही लक्ष ठेवू शकत नसाल.

ही रचना terminal वर मनुष्य लक्ष ठेवत आहे असे गृहीत धरते. Laptop वर हे गृहीतक खरे असते. Server वर मात्र अनेकदा कोणीही लक्ष ठेवत नसते. तुम्ही tmux मध्ये दीर्घकाळ चालणारे task सुरू करून झोपी जाता. अशा वेळी agent ने प्रश्न विचारण्यासाठी काम थांबवले, तर सकाळपर्यंत कोणतीही प्रगती होत नाही. या विलंबामुळे वेळेबरोबरच खर्चही वाढतो, कारण निष्क्रिय Claude Code session मधील warm prompt cache नष्ट होते आणि पुढील turn मध्ये तो cache पुन्हा तयार करण्यासाठी शुल्क आकारले जाते. Server वर लोक skip flag वापरण्याचे खरे कारण हेच आहे आणि तो सोडवणारी समस्या वास्तविक आहे. उर्वरित मार्गदर्शकाचा उद्देश प्रत्येक guardrail सोडून न देता ही समस्या सोडवणे हा आहे.

--dangerously-skip-permissions मुळे काय बदलते

claude --dangerously-skip-permissions approval step बंद करते. Prompt न दाखवता edits होतात. Prompt न दाखवता shell commands चालतात. सामान्यतः संवेदनशील locations चे संरक्षण करणाऱ्या protected-path checks देखील वगळल्या जातात. तुमचे explicit deny rules लागू राहतात आणि काही अत्यंत धोकादायक actions साठी अजूनही confirmation मागितली जाते. मात्र कार्यपद्धतीचा सारांश सोपा आहे: model ने जे run करण्याचे ठरवले, ते run होते.

Server वर या flag संदर्भात दोन तथ्ये महत्त्वाची आहेत. पहिले, Linux आणि macOS वर Claude Code root म्हणून किंवा sudo अंतर्गत चालवल्यास हा flag block केला जातो. कारण prompt नसलेला root machine वरील कोणतीही file किंवा service बदलू शकतो. Agent साठी स्वतंत्र unprivileged account आवश्यक असते आणि हा flag त्याची अंमलबजावणी करतो. दुसरे, हा flag model चे behaviour कोणत्याही प्रकारे बदलत नाही. तो human ला प्रक्रियेबाहेर काढतो आणि इतर काहीही बदलत नाही. त्यामुळे एखादी चूक prompt मुळे आधी थांबली असती, ती आता execute होते.

म्हणून वास्तववादी आढावा असा आहे. Permissions skip केल्यावर security चा प्रश्न "agent काही चुकीचे करेल का" असा राहत नाही. तो "एका चुकीच्या action मुळे किती नुकसान होऊ शकते" असा बदलतो. तुम्ही प्रत्येक decision नियंत्रित करण्याचा प्रयत्न थांबवता आणि blast radius नियंत्रित करण्यास सुरुवात करता. याचे उत्तर containment आहे आणि ते अनेक स्तरांत लागू करता येते.

अंतर्भूत Claude Code sandbox

पायऱ्यांकडे जाण्यापूर्वी हे जाणून घ्या: Claude Code आता ते चालवत असलेल्या commands साठी OS-level sandbox देते आणि त्यामुळे लोकांनी skip flag वापरण्याची बहुतेक कारणे दूर होतात. Linux वर filesystem isolation साठी ते bubblewrap वापरते आणि proxy द्वारे network traffic पाठवण्यासाठी socat वापरते. Sandbox मध्ये command फक्त project directory आणि session temp directory मध्ये write करू शकते. तसेच ते network पर्यंत फक्त अशा proxy द्वारे पोहोचू शकते, जी प्रत्येक domain ची allow list शी पडताळणी करते. एखाद्या command ला प्रथमच नवीन domain वापरायचा असल्यास Claude Code तुमची परवानगी मागते.

Session मध्ये /sandbox command वापरून ते सुरू करा. Ubuntu आणि Debian वर आधी आवश्यक असलेली दोन packages install करा:

sudo apt install bubblewrap socat

Ubuntu 24.04 आणि त्यानंतरच्या आवृत्त्यांमध्ये default AppArmor policy मुळे bubblewrap ला आवश्यक असलेले user namespaces तयार करता येत नाहीत. काहीतरी आवश्यक घटक नसल्यास sandbox panel ते सांगते. Claude Code sandboxing documentation मध्ये हे दुरुस्त करणारे छोटे AppArmor profile दिले आहे.

Sandbox मध्ये auto-allow mode आहे. Enforced boundary आता prompt चे काम करत असल्यामुळे sandboxed commands कोणत्याही prompt शिवाय चालतात. Sandbox मध्ये चालू न शकणारे commands नेहमीच्या permission flow कडे परत जातात. त्यामुळे खरोखर असामान्य actions साठी अजूनही परवानगी मागितली जाते. बहुतेक server workflows साठी skip flag च्या जागी हा योग्य पर्याय आहे. कोणतीही सीमा नसण्याऐवजी OS-enforced boundary मिळते आणि त्यामुळे प्रश्नांची संख्या लक्षणीयरीत्या कमी होते.

याच्या मर्यादांबाबत स्पष्ट रहा. Default स्थितीत sandboxed command filesystem मधील बहुतेक भाग वाचू शकते. यात credential files चाही समावेश होतो, जोपर्यंत तुम्ही त्या paths वर प्रवेश नाकारत नाही. यासाठीच sandbox.credentials setting उपलब्ध आहे. Network proxy domain names ची पडताळणी करते, पण traffic स्वतः तपासत नाही. त्यामुळे github.com सारखी व्यापक allow rule data बाहेर पाठवण्यासाठी अजूनही मार्ग ठेवते. Docker यामध्ये काम करत नाही. Sandbox मुळे मूलभूत सुरक्षा पातळी मोठ्या प्रमाणात वाढते. मात्र ती complete isolation boundary नाही. म्हणूनच खालील पायऱ्या अजूनही महत्त्वाच्या आहेत.

कंटेनमेंटची पायरीरचना

विलगीकरण वाढत जाणाऱ्या क्रमाने तीन पायऱ्या आहेत. या सर्व्हरवर इतर कोणत्या गोष्टी चालतात, त्यानुसार सर्वात कमी योग्य पायरी निवडा.

पायरी 1: स्वतंत्र unprivileged user. एजंटसाठी स्वतंत्र account, स्वतंत्र home directory, स्वतंत्र project directory आणि sudo नसलेला प्रवेश द्या:

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

ही account boundary एजंटला तुमच्या files पासून दूर ठेवते: तुमच्या SSH keys आणि मशीनवरील इतर प्रत्येक project पासून. त्यामुळे skip flag वापरणेही शक्य होते, कारण हा flag root म्हणून चालण्यास नकार देतो. हीच प्रत्येक सेवा unprivileged user म्हणून चालवण्याची तत्त्वप्रणाली एजंटला लागू केली आहे. पायरी 1 ज्या गोष्टींना मर्यादा घालत नाही: network आणि सर्वांसाठी वाचनीय असलेल्या मशीनवरील कोणत्याही गोष्टी.

पायरी 2: container. Anthropic एक reference devcontainer प्रकाशित करते. त्यात Claude Code non-root user म्हणून चालतो आणि firewall rules मुळे एजंट कोणत्या hosts पर्यंत पोहोचू शकतो हे मर्यादित राहते. तुम्ही स्वतः तयार केलेला containerही हेच काम करतो. Filesystem तुम्ही mount केलेल्या volumes पर्यंत मर्यादित राहतो आणि egress container च्या rules ने अनुमत केलेल्या ठिकाणांपुरता मर्यादित राहतो. सर्व्हरवर तुम्हाला महत्त्वाच्या इतर सेवा असतील, तर ही योग्य मधली पायरी आहे. तिची मर्यादा अशी की containers host kernel सामायिक करतात. तसेच एका निष्काळजी mount मुळे ही boundary निष्प्रभ होते; container ला /var/run/docker.sock दिल्यास तो संपूर्ण host पर्यंत पोहोचू शकतो.

पायरी 3: स्वतंत्र VPS. सर्वात मजबूत पायरी ही सर्वात सरळ आहे: एजंटला अशी संपूर्ण मशीन द्या ज्यावर तुम्हाला महत्त्वाची कोणतीही गोष्ट नाही. लहान VPS साठी दरमहा काही dollars लागतात. नवीन VPS वरील पहिल्या दहा मिनिटांची runbook वापरून ते सेट करा, स्वच्छ स्थितीचा snapshot घ्या आणि एजंटला काम करू द्या. तिथे इतर काहीही ठेवू नका. Personal SSH key ठेवू नका; फक्त त्या एका repository पुरती मर्यादित deploy key ठेवा. Cloud credentials किंवा production data ठेवू नका. एखादा run चुकला किंवा तुम्हाला फक्त स्वच्छ स्थितीपासून पुन्हा सुरुवात करायची असेल, तर snapshot restore करा किंवा काही मिनिटांत मशीन destroy करून पुन्हा build करा. Blast radius म्हणजे फक्त VPS चे भाडे. या रचनेत --dangerously-skip-permissions भीतीदायक राहत नाही, कारण वास्तववादी सर्वात वाईट परिणाम म्हणजे पुन्हा build केलेला server आणि revoke केलेला एक token.

या पायऱ्या एकत्र वापरता येतात. Disposable VPS वर unprivileged user म्हणून चालणारा sandboxed agent अतिरिक्त खर्च जवळजवळ वाढवत नाही आणि अपयशाच्या शक्यता कंटाळवाण्या बनवतो. कंटाळवाणेपणाच उद्देश आहे.

क्रेडेन्शियलचे संरक्षण करा

इतर सर्व गोष्टींसाठी लागू होणारा मुख्य नियम असा आहे: agent चा user इतर कोणत्याही घटकाशी संबंधित secrets वाचू शकता कामा नये.

API key फक्त agent ला द्या. ती इतर कोणालाही देऊ नका. ती agent च्या user च्या मालकीच्या, mode 600 असलेल्या file मध्ये ठेवा आणि shell सुरू झाल्यावर ती load करा:

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

यानंतर उलट दिशेनेही प्रवेश बंद करा. Debian आणि Ubuntu मध्ये home directories या संगणकावरील प्रत्येक user ला वाचता येतील अशा प्रकारे तयार केल्या जातात. त्यामुळे तुमच्या home directory चे permissions कडक करा: chmod 750 /home/youruser. ls -ld /home/* वापरून तपासा आणि agent च्या account ला list करता येतील अशा सर्व गोष्टींचे permissions दुरुस्त करा.

प्रत्येक token चा scope मर्यादित ठेवा. एका repository पुरता मर्यादित केलेला fine-grained GitHub token किंवा प्रत्येक repository साठी स्वतंत्र deploy key वापरल्यास credential उघड झाल्यावर तुमचे संपूर्ण account धोक्यात येत नाही; फक्त एक project प्रभावित होते. तुम्ही sandbox वापरत असल्यास, त्याच्या credential settings मध्ये ~/.ssh आणि ~/.aws हे read operations साठीही नाकारले आहेत याची खात्री करा. Production credentials या box वर पूर्णपणे ठेवू नका. कारण जो secret तिथे कधीच नव्हता तो agent leak करू शकत नाही. हे secrets self-hosted password manager मध्ये ठेवले असतील, तर तो agent पेक्षा वेगळ्या box वर ठेवा आणि त्याचे स्वतंत्र review करा. कारण Vaultwarden चे कमकुवत भाग admin token आणि backup file आहेत, encrypted vault स्वतः नाही.

Git हे सुरक्षिततेचे जाळे आहे

एजंटने केलेला प्रत्येक बदल तपासता आणि पूर्ववत करता आला पाहिजे. एजंटने branch वर काम केल्यास Git हे दोन्ही कामे विनामूल्य करून देते:

git switch -c agent/refactor-auth

नंतर git diff main...agent/refactor-auth वापरून run चे पुनरावलोकन करा. योग्य बदल merge करा. run निष्फळ ठरल्यास branch delete करा. तीन files मध्ये बदल करणारा run वाचणे सोपे असते. संपूर्ण module पुन्हा लिहिणाऱ्या run पेक्षा तो सकाळी तपासणे अधिक सोपे असते. म्हणूनच एजंटकडून काम करणारा सर्वात लहान बदल करून घेणारे skill उपयुक्त ठरते. Forge च्या बाजूने main branch संरक्षित करा. त्यामुळे एजंटचा token तेथे push करू शकणार नाही आणि कोठेही force-push करू शकणार नाही. Commit history ही तुमच्या झोपेत काय घडले याचा audit log म्हणूनही काम करते. Terminal मधील कोणत्याही प्रमाणातील मागील output पेक्षा हे अधिक उपयुक्त आहे.

नेटवर्क हा नुकसानव्याप्तीचा भाग आहे

एजंट curl चालवू शकतो. या वाक्यात egress ची संपूर्ण समस्या स्पष्ट होते: एजंट जे काही वाचू शकतो ते कुठेतरी पाठवूही शकतो, आणि prompt injection झालेला एजंट तसे करू शकतो. साधा unprivileged user ही मर्यादा घालत नाही, कारण कोणताही user सर्व्हर ज्या ठिकाणी पोहोचू शकतो तिथे पोहोचू शकतो. Sandbox त्याच्या proxy द्वारे domain नुसार ही मर्यादा घालतो. Container स्वतःच्या firewall rules द्वारे ही मर्यादा घालू शकतो. Dedicated VPS मध्ये सुरुवातीपासूनच leak होऊ शकणारी माहिती कमी असते. या तीन पर्यायांपैकी हा सर्वात मजबूत उपाय आहे.

फक्त ufw वापरून egress सोडवण्याचा प्रयत्न करू नका. ufw सर्व outgoing traffic ला default ने परवानगी देतो. तसेच apt, npm, git आणि Claude API यांना परवानगी देणारे outbound rules लिहिणे गुंतागुंतीचे आहे. अशी configuration शांतपणे बिघडू शकते. त्याऐवजी sandbox, container किंवा machine स्तरावर boundary निवडा. तिथे domain allow list किंवा पूर्णपणे स्वतंत्र machine हेच काम स्वच्छपणे करते.

तुम्ही Claude Code चालवण्याऐवजी API वापरून स्वतःचा agent तयार करत असाल, तरीही हेच विचार लागू होतात. VPS वर Claude वापरून AI agent तयार करणे या पद्धतीचे वर्णन करते. त्या agent साठीही तोच dedicated user, तेच scoped tokens आणि तोच disposable box वापरा.

प्रथम सर्व्हरची सुरक्षा मजबूत करा

तुम्ही कोणतीही पातळी निवडली तरी agent तैनात करण्यापूर्वी मशीनवर मूलभूत सुरक्षा व्यवस्था असणे आवश्यक आहे: फक्त SSH keys, root login बंद, default-deny firewall आणि स्वयंचलित security updates. तुमची checklist येथे तयार करा आणि ती एकदा क्रमाने पूर्ण करा:

FAQ

--dangerously-skip-permissions सर्व्हरवर वापरणे सुरक्षित आहे का?

स्वतःहून नाही. हा flag प्रत्येक approval prompt काढून टाकतो. त्यामुळे model ने पहिली चुकीची command तयार करताच ती लगेच चालते. जोखीम मर्यादित ठेवता येत असेल, तर हा व्यवहार्य पर्याय ठरू शकतो: किमान एक dedicated unprivileged user वापरा. पूर्णपणे unattended कामासाठी one project आणि one scoped token असलेला container किंवा disposable VPS वापरा. उत्पादनातील credentials किंवा गमावता न येणारा data असलेल्या machine वर तो कधीही वापरू नका.

Claude Code मध्ये sandbox आहे का?

होय. Claude Code मध्ये shell commands साठी built-in sandbox आहे. तो /sandbox command ने सुरू करता येतो. Linux वर तो bubblewrap आणि macOS वर Seatbelt वापरतो. तो writes फक्त project directory पर्यंत मर्यादित ठेवतो आणि network access अशा proxy मार्फत पाठवतो, जो केवळ approved domains ला परवानगी देतो. त्याचा auto-allow mode sandboxed commands prompts शिवाय चालवतो. त्यामुळे skip flag प्रमाणे interruptions कमी होतात आणि OS-enforced boundary कायम राहते. ही पूर्ण isolation boundary नाही. त्यामुळे unattended runs साठी dedicated user किंवा dedicated machine सोबत तो वापरा.

root म्हणून चालवताना skip flag नकार का देतो?

Permission prompts नसताना root account system वरील कोणतीही file आणि कोणतीही service बदलू शकतो. त्यामुळे Linux आणि macOS वर root किंवा sudo अंतर्गत चालत असताना Claude Code --dangerously-skip-permissions block करतो. हा check bypass करण्याचा प्रयत्न करू नका. Agent साठी एक unprivileged user तयार करा आणि agent त्याच user अंतर्गत चालवा. ही account boundary containment ची पहिली आणि सर्वात कमी खर्चाची पातळी आहे.

Claude Code माझ्या SSH keys आणि .env files वाचू शकतो का?

तो ज्या user म्हणून चालतो, त्या user ला वाचता येणारी कोणतीही गोष्ट वाचू शकतो. Sandbox चे default policy देखील तुम्ही त्यांना deny करेपर्यंत credential paths वाचण्याची परवानगी देते. त्यामुळे agent स्वतःच्या user म्हणून चालवा. तुमची स्वतःची home directory mode 750 किंवा त्याहून कडक permissions सह ठेवा. Sandbox settings मध्ये credential paths deny करा. Production secrets machine वर ठेवूच नका. Machine वर secret कधी ठेवलेले नसेल, तर तो वाचता किंवा leak करता येत नाही.

Claude Code unattended पद्धतीने चालवण्याचा सर्वात सुरक्षित मार्ग कोणता?

Agent work साठीच वापरलेला एक स्वस्त dedicated VPS हा योग्य पर्याय आहे. तो दहा मिनिटांत harden करा आणि clean snapshot तयार ठेवा. Claude Code sandbox सुरू असताना unprivileged user म्हणून चालवा. API key ठेवणारी mode-600 file वापरा. प्रत्येक repository साठी स्वतंत्र deploy key ठेवा. Merge करण्यापूर्वी तुम्ही review केलेल्या branches वरच सर्व work करा. Run मध्ये काही चूक झाल्यास एक token revoke करून snapshot restore करता येतो. त्यामुळे तुमच्या मालकीच्या इतर कोणत्याही गोष्टीवर परिणाम होत नाही.