Headless VPS पर Gemini CLI कैसे सेटअप करें

आप क्या बना रहे हैं

एक हमेशा चालू रहने वाला Gemini CLI जिसे आप अपने सर्वर पर होस्ट करते हैं। इसे SSH के माध्यम से एक्सेस किया जा सकता है और यह लंबे एजेंट कार्यों को चला सकता है जो आपके लैपटॉप बंद करने के बाद भी चलते रहते हैं। इसका इंस्टॉलेशन केवल तीन कमांड्स में हो जाता है। मेहनत वहां लगती है जहाँ डेस्कटॉप वातावरण की अपेक्षा की जाती है: Google का CLI लॉग इन करने के लिए ब्राउज़र खोलना चाहता है, जबकि आपके सर्वर पर ब्राउज़र नहीं है। इसलिए, इस गाइड का अधिकांश हिस्सा 'हेडलेस' (headless) सेटअप पर केंद्रित है। इसमें शामिल हैं: डिस्ट्रो द्वारा न दिया गया Node का नवीनतम वर्ज़न, एक ग्लोबल npm इंस्टॉलेशन जिसे root की आवश्यकता नहीं है, बिना ब्राउज़र के API key के साथ ऑथेंटिकेशन (जिसे आप अपनी shell history से दूर रखते हैं), और tmux ताकि SSH सेशन डिस्कनेक्ट होने पर भी आपका काम बंद न हो।

Gemini CLI एक ओपन-सोर्स (Apache-2.0) Node प्रोग्राम (@google/gemini-cli) है जो Google के Gemini मॉडल्स के साथ संवाद करता है। यह फाइलों को पढ़ और लिख सकता है, शेल कमांड्स चला सकता है और वर्किंग डायरेक्टरी में टूल्स का उपयोग कर सकता है। एक VPS पर यह एक छोटा, हमेशा उपलब्ध रहने वाला एजेंट है जिसे आप काम पर छोड़ सकते हैं। यही कारण है कि जिस अकाउंट से यह चलता है और जो क्रेडेंशियल्स सर्वर पर मौजूद होते हैं, वे यहाँ दी गई किसी भी अन्य सेटिंग से अधिक महत्वपूर्ण हैं।

पूर्वापेक्षाएँ और सामान्य चुनौतियाँ

• एक नया Ubuntu 24.04 KVM VPS, root या sudo एक्सेस के साथ। कोई भी KVM प्लान काम करेगा; CLI स्वयं बहुत हल्का है और idle अवस्था में कुछ सौ MB RAM ही लेता है।
• Node.js 20 या उससे नया वर्ज़न। यह एक अनिवार्य न्यूनतम वर्ज़न है, और डिस्ट्रो पैकेज इससे पुराना है, इसलिए अगला सेक्शन देखें।
• Google APIs के लिए आउटबाउंड HTTPS (port 443)। किसी इनबाउंड पोर्ट की आवश्यकता नहीं है; यह एक क्लाइंट है, सर्वर नहीं, इसलिए इसके लिए कोई फायरवॉल पोर्ट खोलने की जरूरत नहीं है।
• प्रमाणीकरण (authentication) का एक तरीका जिसे सर्वर पर ब्राउज़र की आवश्यकता न हो: या तो Google AI Studio से प्राप्त Gemini API key, या अपनी मशीन पर ब्राउज़र तक एक SSH टनल। API-key वाला तरीका स्क्रिप्ट और बिना निगरानी के चलने वाले रन के लिए सबसे उपयुक्त है।
• Docker या Podman, केवल यदि आप --sandbox आइसोलेशन चाहते हैं। यह वैकल्पिक है और अंत में कवर किया गया है।

वह चुनौती जो सभी को परेशान करती है: फ्रेंडली gemini फर्स्ट-रन लॉगिन फ्लो डेस्कटॉप के लिए बनाया गया है। यह ब्राउज़र खोलने की कोशिश करता है और, एक हेडलेस बॉक्स पर, या तो विफल हो जाता है या आपको एक ऐसा लिंक देता है जो काम नहीं करता। शुरू करने से पहले प्रमाणीकरण का तरीका तय कर लें।

नोट: डिस्ट्रो पैकेज बहुत पुराना है

Ubuntu 24.04 अपने रिपॉजिटरी में Node 18.19.1 और उसके साथ npm 9.2.0 प्रदान करता है। Gemini CLI का package.json, engines: { node: ">=20" } घोषित करता है, और npm डिफ़ॉल्ट रूप से इस विसंगति (mismatch) पर रुकता नहीं है। यह इसे इंस्टॉल कर देता है और एक चेतावनी देता है जो इस अंतर को स्पष्ट करती है:

npm WARN EBADENGINE Unsupported engine {
npm WARN EBADENGINE   package: '@google/gemini-cli@0.50.0',
npm WARN EBADENGINE   required: { node: '>=20' },
npm WARN EBADENGINE   current: { node: 'v18.19.1', npm: '9.2.0' }
npm WARN EBADENGINE }

उस चेतावनी को अनदेखा करने पर CLI एक असमर्थित (unsupported) रनटाइम पर चलता है। ऐसी स्थिति में, जैसे ही यह किसी ऐसे Node 20+ API तक पहुँचता है जिसकी इसे अपेक्षा होती है, यह गलत व्यवहार करता है या क्रैश हो जाता है। Node 18 का जीवनकाल भी अप्रैल 2025 में समाप्त हो चुका है, इसलिए यह किसी भी स्थिति में सही विकल्प नहीं है। CLI इंस्टॉल करने से पहले एक वर्तमान LTS इंस्टॉल करें। इसके दो साफ-सुथरे तरीके हैं: NodeSource (एक सिस्टम-व्यापी हस्ताक्षरित apt रिपॉजिटरी) या nvm (एक प्रति-उपयोगकर्ता वर्ज़न मैनेजर)। इनमें से एक चुनें।

NodeSource, यदि आप चाहते हैं कि Node बॉक्स पर प्रत्येक उपयोगकर्ता के लिए उपलब्ध हो:

sudo apt-get update
sudo apt-get install -y ca-certificates curl gnupg
curl -fsSL https://deb.nodesource.com/setup_24.x | sudo -E bash -
sudo apt-get install -y nodejs
node --version

node --version को v20.x या उससे अधिक प्रिंट करना चाहिए, v24.x वर्तमान सक्रिय LTS है। वर्तमान सेटअप स्क्रिप्ट के लिए NodeSource पेज देखें; URL में मौजूद setup_24.x वह लाइन है जिसे नया LTS आने पर अपडेट करना होता है।

nvm, यदि आप Node को केवल एक उपयोगकर्ता के होम डायरेक्टरी में रखना चाहते हैं और उसे sudo के साथ कभी नहीं छूना चाहते हैं:

curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.40.1/install.sh | bash
source ~/.bashrc
nvm install --lts
node --version

इस URL में मौजूद v0.40.1 इस लेख को लिखते समय वर्तमान था; नवीनतम रिलीज़ के लिए nvm का README देखें और इसे चलाने से पहले वर्ज़न को बदल लें। इस कार्य के लिए nvm का एक वास्तविक लाभ है: यह Node और उसके ग्लोबल पैकेजों को ~/.nvm के अंतर्गत इंस्टॉल करता है, इसलिए अगले सेक्शन में आने वाली ग्लोबल-इंस्टॉल अनुमति की समस्या कभी नहीं होती है। यदि आप nvm का विकल्प चुनते हैं, तो आप npm-prefix वाले चरण को छोड़ सकते हैं।

sudo npm -g के बिना CLI इंस्टॉल करना

आकर्षक कमांड sudo npm install -g @google/gemini-cli है। इसे न चलाएं। root के स्वामित्व वाला global prefix बाद के हर इंस्टॉलेशन पर permission errors पैदा करता है और आपके npm cache में root के स्वामित्व वाली फाइलें छोड़ देता है, जो महीनों बाद समस्या पैदा करती हैं। सिस्टम Node पर एक साधारण (बिना sudo के) npm install -g चलाएं और आपको दूसरी विफलता मिलेगी:

npm error code EACCES
npm error syscall mkdir
npm error path /usr/lib/node_modules/@google
npm error errno -13
npm error Error: EACCES: permission denied, mkdir '/usr/lib/node_modules/@google'

यह npm है जो /usr/lib में लिखने की कोशिश कर रहा है, जिसे आपका user नहीं लिख सकता। इसका समाधान sudo नहीं है, बल्कि npm के global prefix को अपनी home directory की ओर इंगित करना है ताकि global इंस्टॉलेशन ऐसी जगह हों जहाँ आपका स्वामित्व हो:

mkdir -p ~/.npm-global
npm config set prefix ~/.npm-global
echo 'export PATH="$HOME/.npm-global/bin:$PATH"' >> ~/.bashrc
source ~/.bashrc
npm install -g @google/gemini-cli
gemini --version

~/.bashrc, न कि ~/.profile, जानबूझकर है: tmux, जिसके अंदर आप दो सेक्शन बाद CLI चलाएंगे, एक non-login shell शुरू करता है जो ~/.bashrc को पढ़ता है और ~/.profile को छोड़ देता है। इसलिए गलत फाइल में PATH लाइन होने से gemini ठीक उसी जगह अदृश्य हो जाता है जहाँ आपको इसकी आवश्यकता है। gemini --version का वर्ज़न नंबर प्रिंट करना ही पूरा टेस्ट है। यदि इसके बजाय आपको gemini: command not found मिलता है, तो आपका PATH export लागू नहीं हुआ है, विफलता के प्रकार देखें। nvm पर, prefix लाइनों को पूरी तरह छोड़ दें: यह पहले से ही globals को आपके home के अंदर इंस्टॉल करता है।

यदि आपने पहले किसी बिंदु पर sudo npm चलाया था और अब Your cache folder contains root-owned files दिखाई देता है, तो इसे sudo chown -R $(id -u):$(id -g) ~/.npm के साथ एक बार ठीक करें।

Headless auth की समस्या और इससे निपटने के तरीके

पहली बार gemini को इंटरैक्टिव रूप से चलाने पर यह आपको अपने Google account से लॉग इन करने का विकल्प देता है। डेस्कटॉप पर यह एक ब्राउज़र टैब खोलता है। Headless VPS पर कोई ब्राउज़र नहीं होता, इसलिए यह प्रक्रिया या तो एक localhost URL प्रिंट करती है जिसे आपको खोलने की अपेक्षा होती है, या फिर सीधे विफल हो जाती है:

Failed to open browser. Please visit the following URL to authorize:
https://accounts.google.com/o/oauth2/v2/auth?...&redirect_uri=http://localhost:PORT

यहाँ समस्या redirect_uri=http://localhost:PORT है। भले ही आप उस URL को अपने लैपटॉप पर खोलें और उसे अनुमति दें, Google आपको http://localhost:PORT पर रीडायरेक्ट करता है, जो सर्वर का localhost है। यह एक ऐसा पोर्ट है जिस तक आपके लैपटॉप से नहीं पहुँचा जा सकता। इसलिए लॉग इन कभी पूरा नहीं होता।

इससे निपटने के दो सही तरीके हैं।

पहला तरीका API key का उपयोग करना है, और सर्वर के लिए यही सबसे उपयुक्त डिफ़ॉल्ट है। Google AI Studio (aistudio.google.com) में एक key बनाएँ और उसे environment variable के रूप में CLI को दें; यह GEMINI_API_KEY को पढ़ता है और ब्राउज़र वाली प्रक्रिया को पूरी तरह छोड़ देता है। अब "इसे history और world-readable फाइलों से दूर रखने" वाले हिस्से पर ध्यान दें। प्रॉम्प्ट पर export GEMINI_API_KEY=AIza... टाइप न करें, क्योंकि यह cleartext में ~/.bash_history में सेव हो जाता है, और इसे ऐसी फाइल में भी न रखें जिसे दूसरे पढ़ सकें। इसे mode-600 वाली फाइल में लिखें जिसे शेल शुरू होते ही सोर्स कर ले:

umask 077
printf 'export GEMINI_API_KEY=%s\n' 'AIzaSyYOUR_KEY_HERE' > ~/.gemini_env
chmod 600 ~/.gemini_env
echo '[ -f ~/.gemini_env ] && . ~/.gemini_env' >> ~/.bashrc
source ~/.bashrc

chmod 600 का अर्थ है कि केवल आपका यूजर ही इस फाइल को पढ़ सकता है। printenv GEMINI_API_KEY के साथ पुष्टि करें कि key environment तक पहुँच गई है; यदि यह कुछ भी प्रिंट नहीं करता है, तो CLI वापस ब्राउज़र फ्लो पर चला जाएगा और विफल हो जाएगा। यदि आप उस लेआउट को पसंद करते हैं, तो यह ~/.gemini/ में एक .env फाइल को भी पढ़ता है, नियम वही है, इसलिए chmod 600 ~/.gemini/.env का पालन करें।

दूसरा तरीका OAuth callback को अपने लैपटॉप पर टनल करके व्यक्तिगत Google account लॉग इन (और इसके फ्री टियर) को बनाए रखना है। समस्या यह है कि CLI का लूपबैक सर्वर हर बार एक random पोर्ट bind करता है, इसलिए जब तक आप इसे OAUTH_CALLBACK_PORT environment variable के साथ पिन नहीं करते, तब तक फॉरवर्ड करने के लिए कुछ भी स्थिर नहीं होता। इसके बाद ही उस पोर्ट को फॉरवर्ड करें:

# from your laptop, forward the callback port into the SSH session:
ssh -L 8085:localhost:8085 user@your-server
# then, on the server, pin the callback to the same port and start the CLI:
export OAUTH_CALLBACK_PORT=8085
gemini

CLI ब्राउज़र नहीं खोल सकता, इसलिए यह auth URL प्रिंट करता है; इसे अपने लैपटॉप के ब्राउज़र में खोलें, अनुमति दें, और जब Google http://localhost:8085/... पर रीडायरेक्ट करेगा, तो SSH फॉरवर्ड इसे VPS पर लूपबैक सर्वर तक ले जाएगा और लॉग इन पूरा हो जाएगा। यदि आप पोर्ट को पिन नहीं करते हैं, तो यह हर बार एक नए रैंडम पोर्ट पर लैंड करेगा, जिसे पहले से सेट किया गया कोई भी ssh -L नहीं पकड़ पाएगा। यह काम तो करता है, लेकिन इसके लिए आपको ब्राउज़र के सामने बैठना पड़ता है, इसलिए यह स्क्रिप्ट के लिए उपयुक्त नहीं है। जो कुछ भी आप बैकग्राउंड में चलाना चाहते हैं, उसके लिए API key का उपयोग करें।

AI Studio के बजाय Vertex AI या Google Cloud प्रोजेक्ट के लिए, GOOGLE_GENAI_USE_VERTEXAI=true के साथ GOOGLE_API_KEY सेट करें, या Code Assist लाइसेंस के लिए GOOGLE_CLOUD_PROJECT सेट करें। इसमें भी वही environment-variable अनुशासन और mode-600 फाइल का नियम लागू होता है।

इसे tmux के भीतर चलाएं ताकि SSH session टूटने पर यह बंद न हो

gemini process जिसे आप सीधे अपने SSH shell से launch करते हैं, वह उस shell का child होता है। connection टूटने, laptop बंद होने, Wi-Fi डिस्कनेक्ट होने या idle timeout होने पर, sshd pseudo-terminal को हटा देता है, shell को SIGHUP मिलता है, और वह CLI को बंद कर देता है। फाइलों को edit करते समय दस मिनट बाद भी चल रहा task इसके साथ ही समाप्त हो जाता है, और reconnect करने पर recover करने के लिए कोई process नहीं बचती।

tmux इस समस्या को हल करता है क्योंकि यह shell का स्वामित्व ले लेता है, न कि sshd। यह tmux के भीतर remote VPS पर AI coding agent चलाने के समान ही पैटर्न है, और यहाँ भी यह बिल्कुल वैसे ही काम करता है:

sudo apt install -y tmux
tmux new -A -s gemini
# inside the session:
gemini
# detach with Ctrl-b then d — the task keeps running
# reconnect later from any machine:
tmux attach -t gemini

tmux new -A -s gemini यदि gemini नाम का session मौजूद है तो उससे जुड़ जाता है और यदि नहीं है तो उसे बना देता है, इसलिए हर login के तुरंत बाद चलाने के लिए यही एकमात्र command है। इसके भीतर का shell detached tmux server का होता है, न कि आपके SSH session का, इसलिए connection टूटने पर भी CLI काम करता रहता है। Reconnect करें, attach करें, और आप वापस उसी scrollback पर होंगे। यदि आप एक ही box पर कई agent sessions चलाते हैं, हर tmux session में एक, तो यहाँ उनके आपस में बात करने का कोई तरीका नहीं है, Claude Code के विपरीत जहाँ एक session उसी VPS पर दूसरे को text भेज सकता है, इसलिए हर Gemini job को स्वतंत्र रखें या disk पर मौजूद फाइलों के माध्यम से उन्हें coordinate करें।

Non-interactive, scripted runs के लिए, Gemini CLI में एक headless mode होता है: gemini -p "summarise the failing tests in this repo" उत्तर print करके exit हो जाता है, और --output-format json कहीं और pipe करने के लिए machine-readable output देता है। API key के साथ headless mode वही है जो आप एक लंबे batch job को चलाने वाले tmux session के भीतर चाहते हैं, या जिसे cron entry से चलाया गया हो, बस एक सावधानी के साथ: cron job आपकी किसी भी login file को source नहीं करता है, इसलिए crontab line को अपना GEMINI_API_KEY दें (या command को ~/.gemini_env source करने के लिए कहें), अन्यथा CLI browser flow पर वापस चला जाएगा और विफल हो जाएगा।

प्रोडक्शन चलाने वाले सर्वर पर सैंडबॉक्सिंग और अनुमतियाँ

शेल एक्सेस वाला एजेंट एक शेल ही होता है। Gemini CLI कमांड चला सकता है, और डिफ़ॉल्ट रूप से यह प्रत्येक जोखिम भरे कमांड से पहले पूछता है, लेकिन लोग --yolo (हर टूल कॉल को स्वतः स्वीकृत करना) का उपयोग करने लगते हैं। इसके बाद यह फ़ाइलों को हटा सकता है, git पर पुश कर सकता है, या जिस उपयोगकर्ता के रूप में यह चल रहा है, उसके पूर्ण अधिकारों के साथ आंतरिक सेवाओं तक पहुँच सकता है। जिस सर्वर पर प्रोडक्शन चल रहा हो, वहाँ यह एक वास्तविक खतरा है, न कि केवल काल्पनिक।

तीन नियंत्रण, उनके लाभ के क्रम में:

• इसे एक समर्पित, अनप्रिविलेज्ड (unprivileged) उपयोगकर्ता के रूप में चलाएँ। न root, न sudo का सदस्य। एक agent उपयोगकर्ता बनाएँ जिसका अपना होम डायरेक्टरी हो, वहाँ Node और CLI इंस्टॉल करें। इससे गलत निर्देश मिलने पर भी प्रभाव केवल उसी खाते तक सीमित रहेगा। यह सबसे महत्वपूर्ण निर्णय है।
• प्रोडक्शन क्रेडेंशियल्स को सर्वर पर न रखें। कोई प्रोडक्शन ~/.aws/credentials नहीं, प्रोडक्शन से कॉपी किया गया कोई .env नहीं, और न ही ऐसा डेटाबेस पासवर्ड जिसमें किसी महत्वपूर्ण चीज़ का राइट एक्सेस हो। इसे केवल स्टेजिंग या रीड-ओनली क्रेडेंशियल दें।
• इन-बिल्ट सैंडबॉक्स का उपयोग करें। Docker या Podman इंस्टॉल होने पर, gemini --sandbox (या GEMINI_SANDBOX=docker) एजेंट के टूल कॉल्स को होस्ट फ़ाइल सिस्टम और नेटवर्क से अलग एक कंटेनर के अंदर चलाता है। यह अनप्रिविलेज्ड उपयोगकर्ता का विकल्प नहीं है, लेकिन जब एक ही VPS पर वास्तविक काम हो रहा हो, तो यह सुरक्षा की एक मजबूत दूसरी परत है।

यदि आप Gemini CLI को अन्य self-hosted टूल्स के साथ चला रहे हैं, जैसे कि एक MCP सर्वर जो उसी VPS पर एजेंट को टूल प्रदान करता है, तो प्रत्येक जोड़ी गई क्षमता को उस सतह के रूप में देखें जहाँ तक एजेंट पहुँच सकता है। इसे दिए गए टोकन को केवल एक कार्य तक सीमित रखें।

Quota, cost, और आपके द्वारा चुना गया auth path

Auth path यह तय करता है कि आपसे शुल्क कैसे लिया जाएगा। एक व्यक्तिगत Google account (OAuth path) Gemini Code Assist के free tier का उपयोग करता है, जिसमें प्रति-मिनट और प्रति-दिन की निश्चित सीमाएँ होती हैं; यदि आप इन्हें पार करते हैं, तो window reset होने तक requests में rate-limit error आएगा। AI Studio से प्राप्त API key प्रोजेक्ट के आधार पर free-tier या billed हो सकती है; एक billed key सीमा को बढ़ा देती है और प्रति token शुल्क लेती है। Vertex और Cloud-project auth का बिल Google Cloud के माध्यम से आता है।

दो व्यावहारिक बातें ध्यान रखें। एक unattended agent लूप में बहुत जल्दी quota खत्म कर सकता है, इसलिए इसे cron job पर भरोसा करने से पहले पहली कुछ बार monitor करें। और यदि सर्वर-साइड मॉडल का आपका कारण गोपनीयता या Google के hosted models के बजाय unmetered inference है, तो यह एक अलग टूल है, Ollama के साथ VPS पर open LLM को self-host करना weights और prompts को आपके अपने बॉक्स पर रखता है, लेकिन इसकी कीमत Gemini की तुलना में बहुत छोटा मॉडल चलाने के रूप में चुकानी पड़ती है।

इसे अपडेट रखना

Gemini CLI के नए versions अक्सर आते रहते हैं। चूंकि आपने इसे user-owned prefix में install किया है, इसलिए updates के लिए कभी भी sudo की आवश्यकता नहीं होती है:

npm install -g @google/gemini-cli@latest
gemini --version

इसके अलग-अलग release channels हैं: @latest stable version है, @preview weekly preview है, और @nightly bleeding edge version है। जिन applications पर आप निर्भर हैं, उनके लिए @latest को ही pin करें। nvm पर, global packages सक्रिय Node version के अंतर्गत रहते हैं, इसलिए Node switch करने के लिए nvm use चलाने के बाद आपको CLI को फिर से install करना पड़ सकता है। हर छोटे patch के पीछे भागने के बजाय release notes पढ़ें।

विफलता के प्रकार (Failure modes) और सटीक स्ट्रिंग्स

npm WARN EBADENGINE Unsupported engine ... required: { node: '>=20' }, और उसके बाद रनटाइम पर CLI का क्रैश होना। Node का वर्ज़न बहुत पुराना है, डिस्ट्रो का 18.19.1 वर्ज़न अब end-of-life हो चुका है। NodeSource या nvm से Node 20+ इंस्टॉल करें, node --version के साथ पुष्टि करें, और यदि आपने कई Node वर्ज़न इंस्टॉल किए हैं, तो जाँचें कि which node नए वर्ज़न को पॉइंट कर रहा है, न कि /usr/bin/node को।

npm error code EACCES / permission denied, mkdir '/usr/lib/node_modules/...'। रूट-ओन्ड प्रीफिक्स में ग्लोबल इंस्टॉलेशन। इसे sudo के साथ न चलाएं, npm config set prefix ~/.npm-global सेट करें, ~/.npm-global/bin को PATH पर रखें, और अपने सामान्य यूजर के रूप में पुनः इंस्टॉल करें। यदि किसी पुराने sudo npm ने रूट-ओन्ड कैश फाइलें (Your cache folder contains root-owned files) छोड़ दी हैं, तो sudo chown -R $(id -u):$(id -g) ~/.npm चलाएं।

Failed to open browser, लॉगिन का हैंग होना, या redirect_uri=http://localhost:PORT जिसे आप एक्सेस नहीं कर पा रहे हैं। OAuth फ्लो को ऐसे ब्राउज़र की आवश्यकता होती है जो सर्वर पर मौजूद नहीं है, और इसका localhost कॉलबैक आपके लैपटॉप के बजाय सर्वर को पॉइंट करता है। API-key पाथ (GEMINI_API_KEY) का उपयोग करें, या OAUTH_CALLBACK_PORT को पिन करें, इसे ssh -L के साथ SSH पर फॉरवर्ड करें, और URL को स्थानीय रूप से खोलें।

SSH डिस्कनेक्ट होने पर प्रोसेस का गायब हो जाना। आपने gemini को सीधे SSH शेल से चलाया था, इसलिए यह उस शेल का चाइल्ड प्रोसेस था और डिस्कनेक्ट होने पर pty के साथ समाप्त हो गया। इसे रिकवर नहीं किया जा सकता। हर सेशन को tmux new -A -s gemini के साथ शुरू करें और CLI को उसके अंदर चलाएं।

की (key) सेट होने के बावजूद ऑथेंटिकेशन विफल होना, CLI का वापस ऑथेंटिकेशन पिकर पर आ जाना, या किसी रिक्वेस्ट का HTTP 400 के साथ API key not valid लौटाना। की उस एनवायरनमेंट में नहीं है जिसे CLI देख पा रहा है। printenv GEMINI_API_KEY के साथ पुष्टि करें; यदि यह खाली है, तो आपका ~/.gemini_env कभी सोर्स नहीं हुआ था। जाँचें कि यह लाइन ~/.bashrc में है या नहीं, जिसे इंटरैक्टिव शेल (tmux सहित) पढ़ते हैं, लेकिन cron और अन्य नॉन-इंटरैक्टिव शेल नहीं पढ़ते। की वैल्यू के अंदर एक अतिरिक्त स्पेस या कोट भी API key not valid उत्पन्न करता है।

429 / RESOURCE_EXHAUSTED / रेट-लिमिट संदेश। आप उस कोटे तक पहुँच गए हैं जो आपके ऑथेंटिकेशन टियर के लिए निर्धारित है। विंडो के रीसेट होने का इंतज़ार करें, एजेंट की गति धीमी करें, या पेड API की पर स्विच करें। रीट्राई लूप में फंसा हुआ एजेंट बार-बार इसे हिट करता रहेगा, इसलिए उसे रोकें और जाँचें कि वह क्या कर रहा है।

FAQ

Headless सर्वर पर Gemini CLI को authenticate कैसे करें?

Browser login के बजाय API key का उपयोग करें। Google AI Studio में एक key बनाएँ, इसे mode-600 वाली file में रखें जिसे आपका shell source करता है (export GEMINI_API_KEY=...), और CLI पूरी तरह से OAuth browser flow को छोड़ देगा। यदि आप विशेष रूप से personal-account free tier का उपयोग करना चाहते हैं, तो loopback port को OAUTH_CALLBACK_PORT=8085 के साथ pin करें, इसे ssh -L 8085:localhost:8085 user@server का उपयोग करके अपने laptop पर forward करें, और print किए गए URL को स्थानीय रूप से खोलें। हालाँकि, इसके लिए आपका browser के सामने उपस्थित होना आवश्यक है, इसलिए यह scripts के लिए उपयुक्त नहीं है।

npm global install को sudo की आवश्यकता क्यों होती है, और मैं इससे कैसे बचूँ?

क्योंकि npm का default global prefix /usr/lib/node_modules है, जिस पर आपका user लिख नहीं सकता, इसलिए एक साधारण npm install -g, EACCES error के साथ विफल हो जाता है। इसका गलत समाधान sudo npm -g है, जो root-owned files छोड़ देता है और बाद के installs को खराब कर देता है। सही समाधान prefix को अपने home (npm config set prefix ~/.npm-global) पर point करना और इसके bin को PATH में जोड़ना है, या nvm का उपयोग करना है, जो global packages को आपके home के अंतर्गत स्वचालित रूप से install कर देता है।

disconnect होने के बाद मैं Gemini CLI को कैसे चालू रखूँ?

इसे tmux के अंदर चलाएँ। आपके SSH shell से शुरू की गई process connection टूटने पर समाप्त हो जाती है क्योंकि वह उस shell की child होती है; tmux shell को एक detached server के अंतर्गत चलाता है जो disconnect होने पर भी सक्रिय रहता है। tmux new -A -s gemini का उपयोग करें, अंदर gemini चलाएँ, Ctrl-b d के साथ detach करें, और बाद में tmux attach -t gemini के साथ reattach करें।

क्या production box पर Gemini CLI चलाना सुरक्षित है?

केवल सावधानी के साथ, क्योंकि shell access वाला agent वह सब कुछ कर सकता है जो वह user कर सकता है जिसके रूप में वह चल रहा है। इसे बिना sudo वाले एक समर्पित unprivileged user के रूप में चलाएँ, production credentials को machine से दूर रखें, --yolo auto-approval से बचें, और tool calls को host से अलग करने के लिए --sandbox (Docker या Podman) का उपयोग करें। यह जिस account के अंतर्गत चलता है, वह आपके द्वारा सेट किए गए किसी भी single flag से अधिक महत्वपूर्ण है।

क्या मुझे Gemini CLI के लिए कोई firewall port खोलने की आवश्यकता है?

नहीं। यह एक client है जो Google के APIs को outbound HTTPS calls करता है, इसलिए इसे outbound port 443 की आवश्यकता होती है, लेकिन किसी inbound port की नहीं। यदि आप OAuth tunnel का उपयोग करते हैं, तो pinned callback port (जैसे 8085) localhost पर रहता है और आपके SSH forward के माध्यम से पहुँचा जाता है, न कि किसी खुले inbound port के माध्यम से। Inbound traffic को बंद रखें।