Claude Code टर्मिनल में चलता है, लेकिन सही रनटाइम, डायरेक्टरी अनुमतियाँ, क्रेडेंशियल स्टोरेज और कॉर्पोरेट प्रॉक्सी की तैयारी जरूरी है। यह गाइड बताती है कि लोकल मशीन पर क्या तैयार करें और टीम में कॉन्फ़िगरेशन कैसे साझा करें।
Claude Code एक टर्मिनल टूल है। इंस्टॉल होने के बाद इसे चलाने के लिए एक कमांड ही काफी है, इसलिए बहुत से लोग पूरा ध्यान नेटवर्क पर लगा देते हैं। व्यवहार में रुकावटें अक्सर दूसरी जगह आती हैं: रनटाइम वर्ज़न सही है या नहीं, प्रोजेक्ट डायरेक्टरी में लिखने की अनुमति है या नहीं, keys कहाँ रखी हैं, कंपनी का proxy कैसे इस्तेमाल होगा, और टीम के लोग एक ही configuration कैसे साझा करेंगे।
पहले runtime environment और dependencies को एक जैसा करें
सबसे पहले आधिकारिक documentation में अभी आवश्यक runtime version देखें और वही इंस्टॉल करें। कुछ दिन पहले ही जारी हुए version को प्रयोग के लिए तुरंत न अपनाएँ। package manager भी टीम के अनुसार रखें; npm, pnpm और yarn को मिलाने से lock files में टकराव हो सकता है। git और बुनियादी command-line tools जरूरी हैं, क्योंकि ऐसे tools को repository पढ़नी, commands चलानी और tests run करनी होती हैं। इनमें से कुछ भी गायब हो तो तुरंत error आ सकता है।
इंस्टॉल करने के बाद पहले किसी खाली directory में तीन चीजें जाँचें: file पढ़ना, file बदलना और tests चलाना। छोटी directory में environment की समस्या जल्दी दिखती है; business code के बीच उसे ढूँढना कहीं अधिक महँगा पड़ता है।
Project directory, permissions और सीमाएँ
इसे user के home directory या पूरे drive की root directory से शुरू न करें। इसे साफ़ तौर पर तय repository root दें और read/write access को project के भीतर रखें। अगर किसी काम के लिए सच में बड़ा scope चाहिए, तो स्थायी access खोलने के बजाय one-time permission दें।
Commit करने से पहले .gitignore देखें। लोकल cache, logs और temporary scripts को version control से बाहर रखें। टीम में गंभीर समस्या अक्सर गलत code से नहीं, बल्कि local debugging से बने संवेदनशील files को गलती से commit कर देने से होती है।
Keys और credentials कहाँ रखें
API keys, access tokens और दूसरे secrets को environment variables या operating system के credential manager से दें। इन्हें source code, configuration files या script comments में न लिखें। .env को भी .gitignore में रखें; repository में केवल एक sample file रखें जो fields का अर्थ बताए।
Personal credentials और team credentials अलग रखें। कई लोग एक ही key साझा करेंगे तो समस्या होने पर पता लगाना मुश्किल होगा कि उसे कौन इस्तेमाल कर रहा था। Rotation schedule पहले से तय करें: नियमित रूप से बदलें, किसी व्यक्ति के जाने के दिन बदलें, और leak का संदेह होते ही तुरंत बदलें। Exposure मिले तो पहले credential revoke करें, फिर जाँच करें; logs पहले न हटाएँ।
Corporate proxy और network environment के साथ काम करना
Corporate network में इस तरह के tools के लिए मुश्किल अक्सर connectivity नहीं, बल्कि proxy और certificates होते हैं। अगर enterprise gateway TLS interception करता है, तो certificate chain पर भरोसा न होने के कारण tool सीधे fail हो सकता है। ऐसे में IT से internal root certificate लें और उसे सही trust store में install करें; verification को अस्थायी रूप से बंद न करें।
Login flow browser खोलता है, इसलिए command line और browser के लिए एक ही egress path रखना बेहतर है। यह path fixed, stable और controllable भी होना चाहिए। इनमें से कोई गुण न हो तो बार-बार login या CAPTCHA verification देखने की संभावना बढ़ जाती है। Nodes को बार-बार बदलना एक fixed node की तुलना में verification ज्यादा trigger कर सकता है, क्योंकि fixed node लंबे समय से इस्तेमाल हो रहे user की तरह दिखता है।
Egress सच में लागू है या नहीं, इसे सीधे जाँच सकते हैं: proxy parameter के साथ command line से एक बार IP lookup service पर request भेजें।
curl -x http://127.0.0.1:7897 https://ipinfo.io
दिखने वाला address वही होना चाहिए जिसकी उम्मीद है। Browser की time zone और language को भी egress region से मिलाना बेहतर है; ऐसा न हो कि एक North America दिखाए और दूसरा UTC+8 पर हो।
Team में configuration कैसे साझा करें
Structure साझा करें, secrets नहीं। Working directory की conventions, proxy routing rules, allowed command scope और code style constraints को repository में एक version-controlled configuration file में रखें। Keys हर machine पर environment variables के माध्यम से अलग-अलग inject करें।
नए सदस्य documentation का पालन करके बिना हर सहकर्मी से अलग-अलग पूछे काम शुरू कर सकते हैं। अगर team एक साथ कई identities या environments चलाती है, तो PurpleMark हर environment का browser state स्थिर रख सकता है, ताकि बाद में पता किया जा सके कि कोई खास login किस environment में हुआ था।
समापन
ऐसे tools में समस्या आने का कारण अक्सर tool का अपना bug नहीं, बल्कि prerequisites का सही तरह से aligned न होना होता है। Runtime और dependencies, directory permissions, keys का स्थान, proxy egress और shared configuration—इन पाँच चीजों को छोटे project में पहले व्यवस्थित कर लेने से बाद की बार-बार की troubleshooting कम हो सकती है।
