सर्वर पर Claude Code को सुरक्षित रूप से कैसे चलाएं

सर्वर पर Claude Code को सुरक्षित रूप से चलाने का अर्थ

सर्वर पर Claude Code को सुरक्षित रूप से चलाने के लिए, इसके permission prompts को चालू रखें, इसे एक समर्पित unprivileged user के रूप में चलाएं, और unattended runs को भरोसे के बजाय एक वास्तविक सीमा (boundary) दें: जैसे कि built-in sandbox, एक container, या एक disposable VPS जिसमें आपकी कोई महत्वपूर्ण जानकारी न हो। --dangerously-skip-permissions flag मॉडल और आपके shell के बीच के approval step को हटा देता है। unattended कार्य के लिए यह समझौता उचित हो सकता है, लेकिन केवल ऐसी सीमा के भीतर जो यह सीमित करे कि एक गलत command कहाँ तक पहुँच सकती है। यह गाइड बताती है कि यह flag वास्तव में क्या बदलता है, और अलगाव (isolation) के बढ़ते स्तरों के साथ वह सीमा कैसे बनाई जाए।

Claude Code आपके सर्वर पर क्या कर सकता है

Claude Code एक कोडिंग एजेंट है जो आपके टर्मिनल में चलता है। यह फाइलों को पढ़ता है, फाइलें लिखता है और उसे शुरू करने वाले यूजर के रूप में शेल कमांड चलाता है। यही इस टूल की पूरी उपयोगिता है: यह रिपॉजिटरी को क्लोन कर सकता है, कोड को एडिट कर सकता है, टेस्ट चला सकता है, फेलियर को पढ़ सकता है और बिना आपके हर कमांड टाइप किए कोड को लूप में फिक्स कर सकता है। यदि आपने इसे अभी तक सर्वर पर सेट नहीं किया है, तो running Claude Code on a VPS with tmux में इंस्टॉलेशन और सेशन हैंडलिंग की जानकारी दी गई है। यह पेज उस शक्ति के बारे में है जो आप इसे वहां होने पर देते हैं।

जोखिम वही है जिसे दूसरी बार पढ़ने पर समझा जा सकता है। एक प्रोसेस जो आपके यूजर के रूप में शेल कमांड चलाती है, वह सब कुछ कर सकती है जो आपका यूजर कर सकता है। यह ~/.ssh/id_ed25519, ~/.aws/credentials और हर उस .env फाइल को पढ़ सकती है जिसे आपका यूजर खोल सकता है। यह curl चला सकती है और सर्वर जिस भी होस्ट तक पहुँच सकता है, उसे डेटा भेज सकती है। यह git push --force चला सकती है। एजेंट का अपना कोई उद्देश्य नहीं होता है। खतरा यह है कि कोई टास्क गलत हो जाए, या काम करते समय जो टेक्स्ट उसने पढ़ा उसमें किसी और के द्वारा लिखे गए निर्देश हों: जैसे कोई वेब पेज जिसे उसने फेच किया हो, या किसी इश्यू में कोई कमेंट जिसे फिक्स करने के लिए कहा गया हो। उस दूसरे मामले को प्रॉम्प्ट इंजेक्शन कहा जाता है, और इसीलिए "मॉडल आमतौर पर समझदार होता है" कोई सुरक्षा योजना नहीं है। निर्देश घर के करीब से भी आ सकते हैं, क्योंकि two Claude Code sessions on the same box can send text to each other, और एक सिबलिंग सेशन से आया मैसेज केवल और टेक्स्ट होता है जिसे प्राप्त करने वाला एजेंट पढ़ता है। आप खराब रन के लिए योजना बनाते हैं, औसत रन के लिए नहीं।

अनुमति प्रणाली (permission system) सरल शब्दों में

Manual mode में, Claude Code कोई भी कार्य करने से पहले आपसे अनुमति मांगता है। प्रोजेक्ट के भीतर फाइलों को पढ़ना चुपचाप हो जाता है, लेकिन किसी फाइल को एडिट करने या shell command चलाने से पहले यह आपको सटीक बदलाव या कमांड दिखाता है और आपकी सहमति की प्रतीक्षा करता है। आप एक क्रिया को मंजूरी दे सकते हैं, या इसे दोबारा न पूछने के लिए कह सकते हैं। दूसरा विकल्प फाइल एडिट के लिए केवल वर्तमान session तक सीमित रहता है, लेकिन shell command के लिए यह उस repository और कमांड के लिए स्थायी रूप से save हो जाता है, इसलिए सर्वर पर दी गई त्वरित सहमति session समाप्त होने के बाद भी प्रभावी रहती है। जिन नियमों को आप जानबूझकर बनाए रखना चाहते हैं, उनके लिए settings फाइल में persistent allow, ask, और deny सूचियां होती हैं। उदाहरण के लिए: git status को अनुमति दें, git push पर पूछें, .env को पढ़ने से मना करें। Deny नियम हमेशा प्रभावी रहते हैं। यह आधारभूत स्थिति भी बदल गई है। Auto mode, जहाँ एक क्लासिफायर आपकी जगह क्रियाओं की समीक्षा करता है, 14 August 2026 से Pro, Max, और Team plans पर नए sessions के लिए डिफ़ॉल्ट बन गया है, और Claude Code v2.1.283 से यह हर प्लान पर interactive terminal और VS Code sessions के लिए इन-बिल्ट शुरुआती मोड है, जब तक कि आपने कोई डिफ़ॉल्ट पिन न किया हो। इसलिए यह जानना महत्वपूर्ण है कि प्रत्येक अनुमति मोड वास्तव में क्या अनुमति देता है इससे पहले कि आप यह तय करें कि जिस सर्वर को आप देख नहीं सकते, उस पर कौन सा मोड चलना चाहिए।

यह डिज़ाइन मानकर चलता है कि कोई इंसान टर्मिनल देख रहा है, और लैपटॉप पर यह सच है। सर्वर पर, अक्सर स्थिति यह होती है कि कोई नहीं देख रहा होता है। आप tmux के भीतर एक लंबा कार्य शुरू करते हैं और सो जाते हैं, और यदि कोई एजेंट रात के 2 बजे प्रश्न पूछने के लिए रुक जाता है, तो सुबह तक कोई प्रगति नहीं होती। यह ठहराव समय के साथ-साथ पैसे का भी नुकसान करता है, क्योंकि एक idle Claude Code session अपना warm prompt cache खो देता है और अगली बार इसे फिर से बनाने के लिए भुगतान करना पड़ता है। यही वह वास्तविक कारण है कि लोग सर्वर पर skip flag का उपयोग करते हैं, और यह समस्या वास्तविक है। इस गाइड का शेष भाग सभी सुरक्षा उपायों (guardrails) को छोड़े बिना इस समस्या को हल करने के बारे में है।

--dangerously-skip-permissions क्या बदलता है

claude --dangerously-skip-permissions यह approval step को बंद कर देता है। संपादन बिना किसी प्रॉम्प्ट के होते हैं। शेल कमांड बिना किसी प्रॉम्प्ट के चलते हैं। protected-path की जाँच, जो सामान्यतः संवेदनशील स्थानों की सुरक्षा करती है, उसे भी छोड़ दिया जाता है। आपके स्पष्ट deny नियम अभी भी लागू रहते हैं, और कुछ अत्यंत गंभीर क्रियाएं अभी भी पूछने के लिए रुकती हैं, लेकिन कार्य सारांश सरल है: जो कुछ भी मॉडल चलाने का निर्णय लेता है, वह चल जाता है।

सर्वर पर इस फ्लैग के बारे में दो तथ्य महत्वपूर्ण हैं। पहला, जब Claude Code Linux और macOS पर root के रूप में या sudo के अंतर्गत चलता है, तो यह ब्लॉक हो जाता है, क्योंकि बिना प्रॉम्प्ट के root मशीन पर किसी भी फाइल या सर्विस को बदल सकता है। एजेंट को वैसे भी अपने स्वयं के unprivileged अकाउंट की आवश्यकता होती है, और यह फ्लैग उसे लागू करता है। दूसरा, यह फ्लैग मॉडल के व्यवहार को किसी भी तरह से नहीं बदलता है। यह लूप से मानव को हटा देता है और बाकी कुछ नहीं बदलता, इसलिए हर वह गलती जो एक प्रॉम्प्ट पकड़ सकता था, अब निष्पादित हो जाती है।

तो यहाँ ईमानदार गणना है। यदि आप अनुमतियों को छोड़ते हैं, तो सुरक्षा प्रश्न "क्या एजेंट कुछ बुरा करेगा" से बदलकर "एक गलत क्रिया कितना नुकसान कर सकती है" हो जाता है। आप हर निर्णय को नियंत्रित करने का प्रयास करना बंद कर देते हैं और blast radius को नियंत्रित करना शुरू कर देते हैं। containment ही इसका उत्तर है, और यह चरणों में आता है।

इन-बिल्ट Claude Code सैंडबॉक्स

कमांड्स चलाने से पहले यह जान लें कि Claude Code अब अपने द्वारा चलाए जाने वाले कमांड्स के लिए OS-स्तर का सैंडबॉक्स प्रदान करता है। यह उन अधिकांश कारणों को समाप्त कर देता है जिनके लिए लोग skip फ्लैग का उपयोग करते थे। Linux पर यह फाइलसिस्टम आइसोलेशन के लिए bubblewrap का उपयोग करता है, और नेटवर्क ट्रैफिक को प्रॉक्सी के माध्यम से रूट करने के लिए socat का। सैंडबॉक्स के भीतर, एक कमांड केवल प्रोजेक्ट डायरेक्टरी और एक सेशन टेम्प डायरेक्टरी में ही लिख सकता है। यह नेटवर्क तक केवल उसी प्रॉक्सी के माध्यम से पहुँच सकता है जो हर डोमेन को एक 'allow list' के विरुद्ध जाँचती है। जब कोई कमांड पहली बार किसी नए डोमेन का उपयोग करना चाहता है, तो Claude Code आपसे पूछता है; ऑटो मोड में, क्लासिफायर इसके बजाय नए होस्ट की समीक्षा करता है।

इसे एक सेशन के भीतर /sandbox कमांड के साथ चालू करें। Ubuntu और Debian पर, पहले उन दो पैकेजों को इंस्टॉल करें जिनकी इसे आवश्यकता है:

sudo apt install bubblewrap socat

Ubuntu 24.04 और उसके बाद के वर्ज़न पर, डिफ़ॉल्ट AppArmor पॉलिसी bubblewrap को उन यूजर नेमस्पेस (user namespaces) को बनाने से रोकती है जिनकी उसे आवश्यकता होती है। जब कुछ गायब होता है तो सैंडबॉक्स पैनल आपको सूचित करता है, और Claude Code सैंडबॉक्सिंग डॉक्यूमेंटेशन में वह संक्षिप्त AppArmor प्रोफाइल मौजूद है जो इसे ठीक करती है।

सैंडबॉक्स में एक ऑटो-अलाउ मोड है: सैंडबॉक्स कमांड्स बिना किसी प्रॉम्प्ट के चलते हैं, क्योंकि लागू की गई सीमा (boundary) अब वह काम करती है जो पहले प्रॉम्प्ट करता था। जो कमांड्स सैंडबॉक्स के भीतर नहीं चल सकते, वे सामान्य अनुमति प्रवाह (permission flow) पर वापस आ जाते हैं, इसलिए वास्तव में असामान्य क्रियाओं के लिए अभी भी पूछा जाता है। अधिकांश सर्वर वर्कफ़्लो के लिए यह skip फ्लैग का सही विकल्प है, क्योंकि आपको शून्य के बजाय OS-प्रवर्तित सीमा के साथ बहुत कम प्रश्न मिलते हैं।

इसकी सीमाओं के बारे में स्पष्ट रहें। डिफ़ॉल्ट रूप से, एक सैंडबॉक्स कमांड अभी भी अधिकांश फाइलसिस्टम को पढ़ सकता है, जिसमें क्रेडेंशियल फाइलें भी शामिल हैं, जब तक कि आप उन पाथ्स को डिनाई न कर दें; sandbox.credentials सेटिंग ठीक इसी उद्देश्य के लिए मौजूद है। नेटवर्क प्रॉक्सी डोमेन नामों की जाँच करती है और स्वयं ट्रैफिक का निरीक्षण नहीं करती है, इसलिए github.com जैसा व्यापक अलाउ अभी भी डेटा बाहर भेजने की गुंजाइश छोड़ता है। Docker इसके भीतर काम नहीं करता है। सैंडबॉक्स सुरक्षा के स्तर को काफी बढ़ा देता है। यह एक पूर्ण आइसोलेशन बाउंड्री नहीं है, यही कारण है कि नीचे दिए गए चरण अभी भी महत्वपूर्ण हैं।

कंटेनमेंट लैडर (Containment ladder)

अलगाव (isolation) के बढ़ते क्रम में तीन चरण। वह सबसे निचला चरण चुनें जो इस बात से मेल खाता हो कि सर्वर पर और क्या चल रहा है।

चरण 1: एक समर्पित अनप्रिविलेज्ड यूजर (dedicated unprivileged user)। एजेंट को अपना खुद का अकाउंट, अपनी होम डायरेक्टरी, अपनी प्रोजेक्ट डायरेक्टरी मिलती है और कोई sudo एक्सेस नहीं होता:

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

अकाउंट की सीमा एजेंट को आपकी फाइलों से दूर रखती है: जैसे आपकी SSH keys और मशीन पर मौजूद अन्य सभी प्रोजेक्ट्स। यह skip फ्लैग को भी उपयोग के योग्य बनाता है, क्योंकि यह फ्लैग root के रूप में चलने से इनकार कर देता है। यह हर सर्विस को अनप्रिविलेज्ड यूजर के रूप में चलाने के सिद्धांत जैसा ही है, जिसे एजेंट पर लागू किया गया है। चरण 1 जिस चीज को सीमित नहीं करता है, वह है नेटवर्क और बॉक्स पर मौजूद कोई भी ऐसी चीज जो world-readable है।

चरण 2: एक कंटेनर (container)। Anthropic एक रेफरेंस devcontainer पब्लिश करता है जो Claude Code को non-root यूजर के रूप में चलाता है, जिसमें फायरवॉल रूल्स होते हैं जो यह सीमित करते हैं कि एजेंट किन होस्ट्स तक पहुँच सकता है। आप जो कंटेनर खुद बनाते हैं, वह भी यही काम करता है। फाइलसिस्टम उन वॉल्यूम्स तक सीमित हो जाता है जिन्हें आप माउंट करते हैं, और बाहर जाने वाला ट्रैफिक (egress) कंटेनर के रूल्स द्वारा सीमित हो जाता है। जब सर्वर पर अन्य महत्वपूर्ण सर्विसेज चल रही हों, तो यह सही मध्यम चरण है। इसकी सीमा यह है कि कंटेनर होस्ट कर्नल को साझा करते हैं, और एक लापरवाही से किया गया माउंट इस सीमा को खत्म कर देता है; यदि आप कंटेनर को /var/run/docker.sock दे देते हैं, तो वह पूरे होस्ट तक पहुँच सकता है।

चरण 3: एक समर्पित VPS। सबसे मजबूत चरण सबसे सरल है: एजेंट को एक पूरी मशीन दें जिसमें आपके काम की कोई चीज न हो। एक छोटा VPS कुछ डॉलर प्रति माह में मिल जाता है। इसे नए VPS पर शुरुआती दस मिनट के रनबुक के साथ सेट करें, क्लीन स्टेट का स्नैपशॉट लें और एजेंट को काम करने दें। वहाँ और कुछ न रखें। कोई पर्सनल SSH key नहीं, केवल एक deploy key जो उस एक रिपॉजिटरी तक सीमित हो। कोई क्लाउड क्रेडेंशियल्स नहीं, कोई प्रोडक्शन डेटा नहीं। जब कोई रन गलत हो जाए, या जब आप बस एक क्लीन स्लेट चाहते हों, तो स्नैपशॉट रिस्टोर करें या कुछ ही मिनटों में सर्वर को नष्ट करके दोबारा बना लें। ब्लास्ट रेडियस केवल किराए तक सीमित है। यह वह सेटअप है जहाँ --dangerously-skip-permissions डरावना नहीं रह जाता, क्योंकि सबसे बुरा वास्तविक परिणाम एक रीबिल्ट सर्वर और एक रिवोक किया गया टोकन ही हो सकता है।

ये चरण एक-दूसरे के ऊपर काम करते हैं। एक डिस्पोजेबल VPS पर, अनप्रिविलेज्ड यूजर के रूप में चलने वाला एक सैंडबॉक्स्ड एजेंट, अतिरिक्त खर्च लगभग शून्य रखता है और विफलता की कहानियों को उबाऊ बना देता है। उबाऊ होना ही लक्ष्य है।

Credentials को सुरक्षित रखें

वह नियम जो बाकी सभी सुरक्षा सुनिश्चित करता है: agent के user को किसी अन्य चीज़ के secrets पढ़ने की अनुमति नहीं होनी चाहिए।

API key केवल agent को दें और किसी और को नहीं। इसे agent के user के स्वामित्व वाली एक file में mode 600 के साथ रखें, और 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 installs पर, और installation के दौरान बनाए गए account के लिए, home directories को box पर मौजूद हर user द्वारा पढ़ा जा सकता है, इसलिए अपनी directory को सुरक्षित करें: chmod 750 /home/youruser। ls -ld /home/* के साथ जाँचें और ऐसी किसी भी चीज़ को ठीक करें जिसे agent का account list कर सकता है।

हर token का दायरा सीमित करें। एक repository तक सीमित fine-grained GitHub token, या प्रति-repository deploy key का मतलब है कि credential लीक होने पर केवल एक project प्रभावित होगा, न कि आपका पूरा account। यदि आप sandbox का उपयोग करते हैं, तो उसकी credential settings जोड़ें ताकि ~/.ssh और ~/.aws को reads के लिए भी deny कर दिया जाए। और production credentials को पूरी तरह से box से बाहर रखें, क्योंकि agent उस secret को लीक नहीं कर सकता जो वहां मौजूद ही नहीं है। यदि वे secrets किसी self-hosted password manager में रहते हैं, तो उसे agent से अलग box पर रखें और उसका अपना अलग review करें, क्योंकि Vaultwarden के कमजोर बिंदु admin token और backup file हैं न कि स्वयं encrypted vault।

Git एक सुरक्षा कवच है

एजेंट द्वारा किए गए प्रत्येक commit की समीक्षा की जा सकती है और उसे वापस (revert) किया जा सकता है। यदि एजेंट किसी branch पर काम करता है और साथ-साथ commit करता है, तो git ये दोनों सुविधाएँ मुफ्त में देता है:

git switch -c agent/refactor-auth

जो काम एजेंट commit नहीं करता, उसे यह सुरक्षा नहीं मिलती: git reset --hard ट्रैक की गई फाइलों में किए गए उन बदलावों को हटा देता है जो commit नहीं किए गए हैं, और git repository के बाहर की किसी भी चीज़ को कवर नहीं करता है। रन के बाद git diff main...agent/refactor-auth के साथ समीक्षा करें कि उसने क्या commit किया है, फिर git status और git diff HEAD का उपयोग करके देखें कि उसने क्या commit नहीं किया है। जो बदलाव सही हैं उन्हें merge करें, और यदि रन का कोई परिणाम नहीं निकला तो branch को हटा दें। तीन फाइलों में बदलाव करने वाले रन को सुबह के समय पढ़ना, आधे मॉड्यूल को फिर से लिखने वाले रन की तुलना में कहीं अधिक आसान है, जो एजेंट को सबसे छोटे कार्यशील बदलाव तक सीमित रखने के कौशल का व्यावहारिक उदाहरण है। फोर्ज (forge) स्तर पर main branch को सुरक्षित रखें, ताकि एजेंट का टोकन उस पर push न कर सके और कहीं भी force-push न कर सके। commit history आपके सो जाने के दौरान हुई गतिविधियों के ऑडिट लॉग के रूप में कार्य करती है, जो टर्मिनल के किसी भी स्क्रॉलबैक से अधिक मूल्यवान है।

नेटवर्क ब्लास्ट रेडियस का हिस्सा है

एक एजेंट curl चला सकता है। यह वाक्य पूरी egress समस्या का सार है: एजेंट जो कुछ भी पढ़ सकता है, उसे कहीं भी भेज भी सकता है, और एक प्रॉम्प्ट-इंजेक्टेड एजेंट ऐसा कर सकता है। एक सामान्य unprivileged user इसे सीमित नहीं करता है, क्योंकि कोई भी उपयोगकर्ता उस सब तक पहुँच सकता है जहाँ तक सर्वर पहुँच सकता है। सैंडबॉक्स इसे अपने प्रॉक्सी के माध्यम से डोमेन द्वारा सीमित करता है। एक कंटेनर इसे अपने स्वयं के फायरवॉल नियमों के साथ सीमित कर सकता है। एक समर्पित VPS उस डेटा को सीमित करता है जिसे लीक किया जा सकता है, जो इन तीनों में सबसे मजबूत समाधान है।

केवल ufw के साथ egress समस्या को हल करने का प्रयास न करें। ufw डिफ़ॉल्ट रूप से सभी आउटगोइंग ट्रैफ़िक की अनुमति देता है, और ऐसे आउटबाउंड नियम लिखना जो अभी भी apt, npm, git और Claude API को अनुमति दें, एक जटिल काम है जो चुपचाप विफल हो जाता है। इसके बजाय सैंडबॉक्स, कंटेनर या मशीन स्तर पर सीमा चुनें, जहाँ एक डोमेन अनुमति सूची या एक खाली मशीन वही काम सफाई से करती है।

यदि आप Claude Code चलाने के बजाय API के विरुद्ध अपना स्वयं का एजेंट बना रहे हैं, तो वही सोच बिना किसी बदलाव के लागू होती है। VPS पर Claude के साथ AI एजेंट बनाना उस रास्ते को कवर करता है, और इसके एजेंट को भी उसी समर्पित उपयोगकर्ता, उसी सीमित टोकन और उसी डिस्पोजेबल बॉक्स की आवश्यकता होती है।

सबसे पहले सर्वर को सुरक्षित करें

आप चाहे किसी भी विकल्प को चुनें, एजेंट को इंस्टॉल करने से पहले मशीन पर बुनियादी सुरक्षा उपाय लागू करना आवश्यक है: केवल SSH keys का उपयोग करें, root login को अक्षम करें, default-deny firewall सेट करें और automatic security updates सक्षम करें। अपनी चेकलिस्ट यहाँ तैयार करें और एक-एक करके इन चरणों को पूरा करें:

FAQ

क्या सर्वर पर --dangerously-skip-permissions का उपयोग करना सुरक्षित है?

अकेले यह सुरक्षित नहीं है। यह flag हर स्वीकृति प्रॉम्प्ट (approval prompt) को हटा देता है, इसलिए मॉडल द्वारा पहला गलत कमांड देते ही वह तुरंत निष्पादित हो जाता है। जब इसका प्रभाव सीमित (blast radius contained) हो, तभी इसे अपनाना उचित है: कम से कम एक समर्पित unprivileged user का उपयोग करें, और पूरी तरह से unattended काम के लिए एक container या disposable VPS का उपयोग करें जिसमें केवल एक प्रोजेक्ट और एक सीमित scope वाला token हो। इसे कभी भी ऐसी मशीन पर उपयोग न करें जिसमें production credentials या ऐसा डेटा हो जिसे आप खो नहीं सकते।

क्या Claude Code में sandbox है?

हाँ। Claude Code में shell commands के लिए एक इन-बिल्ट sandbox आता है, जिसे /sandbox कमांड से खोला जाता है। यह Linux पर bubblewrap और macOS पर Seatbelt का उपयोग करता है, प्रोजेक्ट डायरेक्टरी तक लेखन (writes) को सीमित करता है, और नेटवर्क एक्सेस को एक ऐसे प्रॉक्सी के माध्यम से रूट करता है जो केवल स्वीकृत डोमेन की अनुमति देता है। इसका auto-allow मोड बिना प्रॉम्प्ट के sandboxed कमांड चलाता है, इसलिए यह skip flag की तरह ही रुकावटों को कम करता है, जबकि OS-enforced सीमा को बनाए रखता है। यह पूर्ण अलगाव (isolation) की सीमा नहीं है, इसलिए unattended runs के लिए इसे एक समर्पित user या समर्पित मशीन के साथ उपयोग करें।

skip flag root के रूप में चलने से इनकार क्यों करता है?

क्योंकि बिना किसी अनुमति प्रॉम्प्ट के root सिस्टम की किसी भी फाइल और किसी भी सर्विस को संशोधित कर सकता है, इसलिए Claude Code Linux और macOS पर root या sudo के तहत चलने पर --dangerously-skip-permissions को ब्लॉक कर देता है। इसका समाधान इस चेक को बायपास करना नहीं है। एजेंट के लिए एक unprivileged user बनाएँ और उसे वहाँ चलाएँ; वह अकाउंट सीमा सुरक्षा की पहली और सबसे सस्ती परत है।

क्या Claude Code मेरी SSH keys और .env फाइलों को पढ़ सकता है?

यह उन सभी फाइलों को पढ़ सकता है जिन्हें वह user पढ़ सकता है जिसके तहत यह चल रहा है, और यहाँ तक कि sandbox की डिफ़ॉल्ट नीति भी credential paths को पढ़ने की अनुमति देती है जब तक कि आप उन्हें मना न करें। इसलिए एजेंट को उसके अपने user के रूप में चलाएँ, अपनी home directory को mode 750 या उससे अधिक सख्त रखें, sandbox सेटिंग्स में credential paths को deny करें, और production secrets को मशीन पर बिल्कुल न रखें। जिस secret को बॉक्स ने कभी देखा ही नहीं, उसे न तो पढ़ा जा सकता है और न ही लीक किया जा सकता है।

Claude Code को unattended चलाने का सबसे सुरक्षित तरीका क्या है?

एक सस्ता समर्पित VPS जिसका उपयोग केवल एजेंट के काम के लिए किया जाए: इसे दस मिनट में हार्डन करें, इसका clean snapshot लें, Claude Code को एक unprivileged user के तहत sandbox ऑन करके चलाएँ, API key को mode-600 वाली फाइल में रखें, प्रति-रिपॉजिटरी (per-repository) deploy key का उपयोग करें, और सारा काम उन branches पर करें जिन्हें आप मर्ज करने से पहले रिव्यू करते हैं। यदि कोई रन गलत हो जाता है, तो आप एक token को revoke कर सकते हैं और snapshot को रिस्टोर कर सकते हैं, जिससे आपकी अन्य किसी भी चीज़ पर कोई प्रभाव नहीं पड़ेगा।