सर्वर पर 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, और एक सिबलिंग सेशन से आया मैसेज केवल और टेक्स्ट होता है जिसे प्राप्त करने वाला एजेंट पढ़ता है। आप खराब रन के लिए योजना बनाते हैं, औसत रन के लिए नहीं।

अनुमति प्रणाली का सरल विवरण

डिफ़ॉल्ट रूप से, Claude Code कोई भी कार्य करने से पहले आपसे अनुमति मांगता है। प्रोजेक्ट के भीतर फ़ाइलों को पढ़ना चुपचाप हो जाता है, लेकिन किसी फ़ाइल को संपादित करने या शेल कमांड चलाने से पहले, यह आपको सटीक संपादन या कमांड दिखाता है और आपकी सहमति की प्रतीक्षा करता है। आप एक बार के लिए किसी क्रिया को स्वीकृत कर सकते हैं, या उस सत्र के शेष भाग के लिए उस प्रकार की क्रियाओं को स्वीकृत कर सकते हैं। ये स्वीकृतियां केवल वर्तमान सत्र तक सीमित होती हैं: CLI से बाहर निकलने पर, अगला सत्र फिर से सावधानी के साथ शुरू होता है। जिन नियमों को आप स्थायी रखना चाहते हैं, उनके लिए सेटिंग्स फ़ाइल में allow, ask और deny सूचियां होती हैं। उदाहरण के लिए: git status को अनुमति दें, git push पर पूछें, और .env को पढ़ने से मना करें। Deny नियम हमेशा प्रभावी रहते हैं। यह आधारभूत स्तर स्वयं बदल रहा है, क्योंकि 14 August 2026 से auto mode डिफ़ॉल्ट हो जाएगा, इसलिए यह जानना महत्वपूर्ण है कि प्रत्येक अनुमति मोड वास्तव में क्या करने की अनुमति देता है, इससे पहले कि आप यह तय करें कि जिस सर्वर की आप निगरानी नहीं कर सकते, उस पर कौन सा मोड चलना चाहिए।

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

--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 को उन यूजर नेमस्पेस को बनाने से रोकती है जिनकी उसे आवश्यकता होती है। जब कुछ गायब होता है, तो सैंडबॉक्स पैनल आपको सूचित करता है, और Claude Code सैंडबॉक्सिंग डॉक्यूमेंटेशन में वह संक्षिप्त AppArmor प्रोफाइल मौजूद है जो इसे ठीक करती है।

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

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

क्रेडेंशियल्स को सुरक्षित रखें

वह नियम जो बाकी सभी सुरक्षा उपायों का आधार है: एजेंट के यूजर को किसी अन्य चीज से संबंधित सीक्रेट्स (secrets) पढ़ने की अनुमति नहीं होनी चाहिए।

API key केवल एजेंट को दें, किसी और को नहीं। इसे एजेंट के यूजर के स्वामित्व वाली एक फाइल में रखें, जिसका मोड 600 हो, और शेल शुरू होने पर इसे लोड करें:

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 पर, होम डायरेक्टरी अक्सर बॉक्स के हर यूजर के लिए पढ़ने योग्य होती हैं, इसलिए अपनी डायरेक्टरी को सुरक्षित करें: chmod 750 /home/youruser। ls -ld /home/* के साथ जांच करें और ऐसी किसी भी चीज को ठीक करें जिसे एजेंट का अकाउंट लिस्ट कर सकता है।

हर टोकन का दायरा (scope) सीमित करें। एक रिपॉजिटरी तक सीमित GitHub टोकन, या प्रति-रिपॉजिटरी डिप्लॉय की (deploy key) का मतलब है कि क्रेडेंशियल लीक होने पर केवल एक प्रोजेक्ट प्रभावित होगा, न कि आपका पूरा अकाउंट। यदि आप सैंडबॉक्स का उपयोग करते हैं, तो इसकी क्रेडेंशियल सेटिंग्स जोड़ें ताकि ~/.ssh और ~/.aws को पढ़ने के लिए भी मनाही हो। और प्रोडक्शन क्रेडेंशियल्स को पूरी तरह से बॉक्स से बाहर रखें, क्योंकि एजेंट उस सीक्रेट को लीक नहीं कर सकता जो वहां मौजूद ही नहीं है। यदि वे सीक्रेट्स किसी सेल्फ-होस्टेड पासवर्ड मैनेजर में रहते हैं, तो उसे एजेंट से अलग बॉक्स पर रखें और उसका अपना अलग रिव्यू करें, क्योंकि Vaultwarden के कमजोर बिंदु एडमिन टोकन और बैकअप फाइल हैं न कि स्वयं एन्क्रिप्टेड वॉल्ट।

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

एजेंट द्वारा किया गया प्रत्येक बदलाव समीक्षा योग्य और वापस लेने योग्य (revertable) होना चाहिए, और यदि एजेंट किसी branch पर काम करता है तो git आपको ये दोनों सुविधाएँ मुफ्त में देता है:

git switch -c agent/refactor-auth

बाद में git diff main...agent/refactor-auth के साथ run की समीक्षा करें, जो सही है उसे merge करें, और यदि run का कोई परिणाम न निकला हो तो branch को delete कर दें। तीन फाइलों में बदलाव करने वाले run को नाश्ते के समय पढ़ना, आधे module को फिर से लिखने वाले run की तुलना में कहीं अधिक आसान होता है, जो एक ऐसे कौशल का व्यावहारिक उदाहरण है जो एजेंट को सबसे छोटे कार्यशील बदलाव तक सीमित रखता है। Forge स्तर पर main branch को सुरक्षित रखें, ताकि एजेंट का token उस पर push न कर सके और कहीं भी force-push न कर सके। commit history आपके सोए रहने के दौरान हुई गतिविधियों के audit log के रूप में कार्य करती है, जो terminal scrollback की किसी भी मात्रा से अधिक मूल्यवान है।

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

एक एजेंट 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 को रिस्टोर कर सकते हैं, जिससे आपकी अन्य किसी भी चीज़ पर कोई प्रभाव नहीं पड़ेगा।