Headless VPS वर Gemini CLI कसे चालवायचे

तुम्ही काय तयार करत आहात

तुमच्या मालकीच्या सर्व्हरवर चालणारा, SSH द्वारे वापरता येणारा always-on Gemini CLI. तो दीर्घकाळ चालणारी agent tasks पार्श्वभूमीत सुरू ठेवतो, त्यामुळे laptop बंद केल्यानंतरही काम सुरू राहते. Installation साठी तीन commands पुरेसे आहेत. प्रत्यक्ष अडचण desktop गृहीत धरणाऱ्या बाबींमध्ये आहे: Google च्या CLI ला login करण्यासाठी browser उघडायचा असतो, पण तुमच्या server वर browser नसतो. त्यामुळे या मार्गदर्शकाचा बहुतांश भाग headless पद्धतीवर आहे. यात distro देत नसलेली अद्ययावत Node आवृत्ती, root शिवाय करता येणारे global npm install, shell history मध्ये न ठेवता browser शिवाय करता येणारे API key authentication आणि SSH session तुटल्यानंतरही सुरू असलेली task बंद होऊ नये यासाठी tmux यांचा समावेश आहे.

Gemini CLI हा open-source (Apache-2.0) Node program (@google/gemini-cli) आहे. तो Google च्या Gemini models शी संवाद साधतो आणि working directory मधील files वाचू-लिहू शकतो, shell commands चालवू शकतो आणि tools वापरू शकतो. VPS वर हा लहान, नेहमी उपलब्ध असलेला agent म्हणून चालतो. त्यामुळे तो ज्या account अंतर्गत चालतो आणि server वर साठवलेली credentials यांचे महत्त्व या मार्गदर्शकातील कोणत्याही एकाच setting पेक्षा अधिक आहे.

पूर्वतयारी आणि प्रत्यक्ष अडचणी

• root किंवा sudo असलेला नवीन Ubuntu 24.04 KVM VPS. कोणतीही KVM योजना चालते; CLI स्वतः हलका आहे आणि निष्क्रिय स्थितीत काहीशे MB RAM वापरतो.
• Node.js 20 किंवा त्यानंतरची आवृत्ती. ही एकमेव अनिवार्य किमान आवृत्ती आहे. डिस्ट्रो पॅकेज यापेक्षा जुने आहे; पुढील विभाग पहा.
• Google's APIs साठी outbound HTTPS (port 443). inbound ports आवश्यक नाहीत; हा server नसून client आहे, त्यामुळे यासाठी firewall मध्ये कोणतेही छिद्र उघडण्याची गरज नाही.
• server वर browser आवश्यक नसलेली authentication पद्धत: Google AI Studio मधील Gemini API key किंवा तुमच्या स्वतःच्या मशीनवरील browser कडे जाणारा SSH tunnel. scripts आणि unattended runs साठी API-key पद्धत अधिक योग्य आहे.
• Docker किंवा Podman, फक्त --sandbox isolation हवे असल्यास. हे ऐच्छिक आहे आणि शेवटच्या भागाजवळ समजावले आहे.

सर्वांना अडचणीत आणणारी गोष्ट अशी आहे: सोयीची gemini first-run login flow desktop साठी तयार केलेली आहे. ती browser उघडण्याचा प्रयत्न करते. headless box वर ती एकतर अपयशी ठरते किंवा काम न करणारी link देते. सुरुवात करण्यापूर्वी authentication पद्धत ठरवा.

Node: distro पॅकेज खूप जुने आहे

Ubuntu 24.04 च्या स्वतःच्या repositories मध्ये Node 18.19.1 आणि त्यासोबत npm 9.2.0 उपलब्ध आहेत. Gemini CLI चा package.json, engines: { node: ">=20" } घोषित करतो. npm default स्वरूपात ही विसंगती आढळल्यावर प्रक्रिया थांबवत नाही. ते install पुढे सुरू ठेवते आणि हा फरक स्पष्ट करणारी warning दाखवते:

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 }

ही warning दुर्लक्षित केल्यास CLI unsupported runtime वर चालेल. Node 20+ API वापरण्याच्या टप्प्यावर ते चुकीचे वागू शकते किंवा crash होऊ शकते. Node 18 एप्रिल 2025 मध्ये end-of-life झाले आहे. त्यामुळे तो कोणत्याही परिस्थितीत योग्य पर्याय नाही. CLI install करण्यापूर्वी current LTS install करा. यासाठी दोन योग्य मार्ग आहेत: NodeSource (system-wide signed apt repo) किंवा nvm (per-user version manager). यापैकी एक निवडा.

प्रणालीवरील प्रत्येक user साठी Node उपलब्ध हवा असल्यास NodeSource वापरा:

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 ही सध्याची active LTS आवृत्ती आहे. सध्याची setup script पाहण्यासाठी NodeSource चे पृष्ठ तपासा. नवीन LTS उपलब्ध झाल्यावर URL मधील setup_24.x बदलायचे आहे.

Node एका user च्या home मध्येच ठेवायचा असल्यास आणि त्यावर sudo ने कधीही काम करायचे नसल्यास nvm वापरा:

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 current होते. ती command चालवण्यापूर्वी nvm च्या README मध्ये latest release तपासा आणि URL मधील आवृत्ती बदला. या कामासाठी nvm चा महत्त्वाचा फायदा आहे: ते Node आणि त्याची global packages ~/.nvm अंतर्गत install करते. त्यामुळे पुढील section मधील global-install permission ची समस्या उद्भवतच नाही. nvm वापरत असल्यास npm-prefix step वगळू शकता.

sudo npm -g शिवाय CLI स्थापित करा

प्रलोभन देणारी कमांड sudo npm install -g @google/gemini-cli आहे. ती वापरू नका. root-मालकीचा global prefix वापरल्यास पुढील प्रत्येक install वेळी permission errors येतात. तसेच तुमच्या npm cache मध्ये root-मालकीच्या फाइल्स तयार होतात. काही महिन्यांनंतर त्यांमुळे समस्या निर्माण होऊ शकते. System 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 installs तुमच्या मालकीच्या ठिकाणी जातील:

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 ऐवजी मुद्दाम वापरले आहे. तुम्ही CLI ज्या tmux section मध्ये चालवणार आहात, त्याच्या दोन sections आधी tmux non-login shell सुरू करतो. हा shell ~/.bashrc वाचतो आणि ~/.profile वगळतो. त्यामुळे चुकीच्या फाइलमध्ये PATH line ठेवल्यास, तुम्हाला नेमका जिथे त्याची गरज आहे तिथे gemini अदृश्य राहते. gemini --version ने version number दाखवणे हीच पूर्ण चाचणी आहे. त्याऐवजी gemini: command not found दिसल्यास, तुमचे PATH export लागू झालेले नाही. Failure modes विभाग पहा. nvm वापरत असल्यास prefix lines पूर्णपणे वगळा. nvm आधीच globals तुमच्या home directory अंतर्गत स्थापित करतो.

तुम्ही यापूर्वी कधीतरी sudo npm चालवले असेल आणि आता Your cache folder contains root-owned files दिसत असेल, तर sudo chown -R $(id -u):$(id -g) ~/.npm वापरून ते एकदाच दुरुस्त करा.

headless auth ची समस्या आणि तिच्यावर उपाय

पहिल्यांदा gemini परस्परसंवादी पद्धतीने चालवल्यावर ते तुम्हाला Google account ने login करण्याची सुविधा देते. Desktop वर browser tab उघडतो. headless VPS वर browser नसल्यामुळे ही प्रक्रिया एकतर तुम्ही उघडावी अशी 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 laptop वर उघडून परवानगी दिली, तरीही Google http://localhost:PORT कडे redirect करते. हा server वरील localhost असतो. Laptop वरून त्या port पर्यंत पोहोचता येत नाही. त्यामुळे login पूर्ण होत नाही.

यावर दोन योग्य उपाय आहेत.

पहिला उपाय API key वापरणे हा आहे आणि server साठी तोच योग्य default आहे. Google AI Studio (aistudio.google.com) मध्ये key तयार करा आणि ती environment variable म्हणून CLI ला द्या; CLI GEMINI_API_KEY वाचते आणि browser flow पूर्णपणे वगळते. आता “ती history आणि सर्वांना वाचता येणाऱ्या files पासून दूर ठेवणे” हा मुद्दा महत्त्वाचा आहे. Prompt वर export GEMINI_API_KEY=AIza... टाइप करू नका. ती ~/.bash_history मध्ये cleartext स्वरूपात साठते. तसेच इतर users वाचू शकतील अशा file मध्ये ती ठेवू नका. Shell सुरू होताना source करेल अशा mode-600 file मध्ये ती लिहा:

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 याचा अर्थ फक्त तुमचा user ही file वाचू शकतो. printenv GEMINI_API_KEY वापरून key environment मध्ये पोहोचली आहे का ते तपासा. त्यातून काहीही output मिळाले नाही, तर CLI browser flow कडे परतते आणि अपयशी ठरते. तुम्ही तो layout पसंत करत असल्यास ते ~/.gemini/ मधील .env file देखील वाचते. तोच नियम लागू होतो, म्हणून chmod 600 ~/.gemini/.env.

दुसरा उपाय personal-Google-account login आणि त्याचा free tier कायम ठेवतो, पण OAuth callback तुमच्या laptop कडे tunnel करतो. अडचण अशी आहे की CLI चा loopback server प्रत्येक run वेळी random port वर bind होतो. त्यामुळे forward करण्यासाठी स्थिर port उपलब्ध नसतो. आधी OAUTH_CALLBACK_PORT environment variable वापरून port निश्चित करा आणि नंतर नेमका तोच port forward करा:

# 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 browser उघडू शकत नाही, त्यामुळे ते auth URL दाखवते. ती URL तुमच्या laptop वरील browser मध्ये उघडा आणि परवानगी द्या. Google http://localhost:8085/... कडे redirect केल्यावर SSH forward तो callback VPS वरील loopback server कडे पाठवतो आणि login पूर्ण होते. Port निश्चित केला नाही, तर प्रत्येक run वेळी नवीन random port वापरला जातो. त्यामुळे आधीच तयार केलेला कोणताही ssh -L तो पकडू शकत नाही. हा उपाय कार्य करतो, पण browser समोर बसणे आवश्यक आहे. त्यामुळे scripts साठी तो योग्य नाही. दीर्घकाळ चालू ठेवायच्या प्रक्रियांसाठी API key वापरा.

AI Studio ऐवजी Vertex AI किंवा Google Cloud project वापरत असल्यास, GOOGLE_GENAI_USE_VERTEXAI=true सोबत GOOGLE_API_KEY सेट करा. Code Assist licence साठी GOOGLE_CLOUD_PROJECT वापरा. Environment variable बाबत तोच नियम लागू होतो आणि mode-600 file देखील तशीच वापरा.

ते tmux मध्ये चालवा, म्हणजे SSH सत्र तुटल्यावर प्रक्रिया बंद होणार नाही

तुम्ही SSH shell मधून थेट सुरू केलेली gemini प्रक्रिया त्या shell ची child process असते. कनेक्शन तुटणे, laptop बंद होणे, Wi-Fi खंडित होणे किंवा idle timeout यांपैकी काहीही झाले, तर sshd pseudo-terminal बंद करते, shell ला SIGHUP मिळतो आणि तो पुढे CLI कडेही hangup पाठवतो. Files संपादित करण्यास सुरुवात करून दहा मिनिटे झाल्यावर task देखील बंद होतो. पुन्हा connect केल्यावर पुनर्प्राप्त करण्यासाठी कोणतीही प्रक्रिया शिल्लक राहत नाही.

tmux हे shell स्वतःच्या नियंत्रणाखाली ठेवून ही समस्या सोडवते; sshd च्या नियंत्रणाखाली ठेवत नाही. हीच पद्धत remote VPS वर AI coding agent tmux मध्ये चालवताना वापरली जाते आणि येथेही ती तशीच कार्य करते:

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 अस्तित्वात असल्यास त्याला attach करते आणि नसल्यास ते तयार करते. त्यामुळे प्रत्येक login नंतर चालवण्यासाठी हा एकच command पुरेसा आहे. आतला shell तुमच्या SSH session चा नसून detached tmux server चा असतो. त्यामुळे कनेक्शन तुटले तरी CLI कार्यरत राहतो. पुन्हा connect करा, attach करा आणि त्याच scrollback मध्ये परत या. एका server वर अनेक agent sessions चालवल्यास प्रत्येकासाठी स्वतंत्र tmux session वापरा. येथे ते एकमेकांशी संवाद साधू शकत नाहीत. हे Claude Code पेक्षा वेगळे आहे. Claude Code मध्ये त्याच VPS वरील एक session दुसऱ्या session कडे मजकूर पाठवू शकते. त्यामुळे प्रत्येक Gemini job स्वतंत्र ठेवा किंवा disk वरील files द्वारे त्यांच्यात समन्वय साधा.

Non-interactive, scripted runs साठी Gemini CLI मध्ये headless mode आहे: gemini -p "summarise the failing tests in this repo" उत्तर छापते आणि बाहेर पडते, तर --output-format json दुसरीकडे pipe करता येईल असे machine-readable output देते. API key सह headless mode वापरणे tmux session मध्ये दीर्घकाळ चालणारा batch job सुरू करण्यासाठी किंवा cron entry मधून तो चालवण्यासाठी योग्य आहे. मात्र एक महत्त्वाची अट आहे: cron job तुमच्या login files पैकी कोणतीही file source करत नाही. त्यामुळे crontab line मध्ये स्वतंत्र GEMINI_API_KEY द्या किंवा command ने ~/.gemini_env source करेल याची खात्री करा. अन्यथा CLI browser flow कडे वळतो आणि अपयशी ठरतो.

उत्पादन सेवा चालवणाऱ्या सर्व्हरवरील sandboxing आणि permissions

Shell access असलेला agent म्हणजे shell वापरू शकणारा agent. Gemini CLI commands चालवू शकते. Default स्वरूपात, प्रत्येक धोकादायक command आधी ते परवानगी विचारते. मात्र वापरकर्ते --yolo (प्रत्येक tool call साठी आपोआप परवानगी) वापरतात. त्यानंतर ते ज्या user म्हणून चालते, त्या user च्या पूर्ण अधिकारांसह files delete करू शकते, git वर push करू शकते किंवा internal services शी संपर्क साधू शकते. उत्पादन सेवा चालवणाऱ्या सर्व्हरवर यामुळे प्रत्यक्ष आणि मोठा परिणाम होऊ शकतो. हा केवळ काल्पनिक धोका नाही.

खालील तीन controls वापरा. त्यांचा फायदा मिळण्याच्या प्रमाणानुसार क्रम दिला आहे:

• ते स्वतंत्र, unprivileged user म्हणून चालवा. root म्हणून चालवू नका आणि sudo चा member बनवू नका. स्वतंत्र home असलेला agent user तयार करा. Node आणि CLI त्याच user च्या environment मध्ये install करा. त्यामुळे चुकीच्या अर्थाने दिलेली instruction त्या account पुरती मर्यादित राहते. हा सर्वाधिक महत्त्वाचा एकच निर्णय आहे.
• Production credentials सर्व्हरवर ठेवू नका. कोणतेही prod ~/.aws/credentials ठेवू नका. Production मधून कोणतेही .env कॉपी करू नका. महत्त्वाच्या कोणत्याही resource वर write access असलेला database password देऊ नका. त्याऐवजी staging credential किंवा read-only credential द्या.
• Built-in sandbox वापरा. Docker किंवा Podman install केलेले असल्यास, gemini --sandbox (किंवा GEMINI_SANDBOX=docker) agent चे tool calls host filesystem आणि network पासून isolated असलेल्या container मध्ये चालवते. हे unprivileged user चा पर्याय नाही. मात्र त्याच VPS वर प्रत्यक्ष उत्पादन सेवा चालू असताना हा मजबूत दुसरा सुरक्षा स्तर ठरतो.

Gemini CLI इतर self-hosted tooling च्या शेजारी चालवत असल्यास, उदाहरणार्थ त्याच VPS वर agent साठी tools उपलब्ध करून देणारा MCP server, प्रत्येक अतिरिक्त capability मुळे agent ला पोहोचता येणारा attack surface वाढतो असे समजा. Agent ला दिलेले tokens नेमक्या एका कामापुरतेच मर्यादित ठेवा.

कोटा, खर्च आणि तुम्ही निवडलेला auth मार्ग

auth मार्गावरून तुमचे billing कसे होईल हे ठरते. वैयक्तिक Google account (OAuth मार्ग) मोफत Gemini Code Assist tier वापरतो. या tier ला प्रतिमिनिट आणि प्रतिदिन अशा वास्तविक मर्यादा असतात. त्या मर्यादा ओलांडल्यास window reset होईपर्यंत requests rate-limit error परत करतात. AI Studio मधील API key project नुसार free tier वर असू शकते किंवा billed असू शकते. Billed key मुळे मर्यादा वाढतात आणि token नुसार शुल्क आकारले जाते. Vertex आणि Cloud-project auth साठी billing Google Cloud द्वारे केले जाते.

दोन व्यावहारिक नोंदी लक्षात ठेवा. unattended agent loop मध्ये चालू असल्यास quota पटकन संपवू शकतो. त्यामुळे cron job वर त्यावर विश्वास ठेवण्यापूर्वी पहिल्या काही वेळा त्याचे निरीक्षण करा. तसेच, server-side model वापरण्यामागचे कारण Google च्या hosted models ऐवजी privacy किंवा unmetered inference असल्यास, ते वेगळे साधन आहे. Ollama वापरून VPS वर open LLM self-host करणे यामुळे weights आणि prompts तुमच्या स्वतःच्या मशीनवरच राहतात. मात्र त्यासाठी Gemini पेक्षा खूप लहान model चालवावा लागतो.

अद्ययावत ठेवणे

Gemini CLI ची नवीन releases वारंवार येतात. ते user-owned prefix मध्ये install केल्यामुळे updates साठी sudo ची आवश्यकता नसते:

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

Release channels उपलब्ध आहेत: @latest stable आहे, @preview weekly preview आहे, तर @nightly bleeding edge आहे. तुम्ही अवलंबून असलेल्या कोणत्याही environment मध्ये @latest वर pin करा. nvm मध्ये global packages active Node version अंतर्गत साठवले जातात. त्यामुळे Node बदलण्यासाठी nvm use केल्यानंतर CLI पुन्हा install करावे लागू शकते. प्रत्येक patch चा मागोवा घेण्याऐवजी release notes वाचा.

अपयशाच्या स्थिती, अचूक strings सह

npm WARN EBADENGINE Unsupported engine ... required: { node: '>=20' }, त्यानंतर runtime मध्ये CLI crash होणे. Node ची आवृत्ती जुनी आहे. Distro मध्ये 18.19.1 आहे आणि ती देखील end-of-life नंतरची आहे. NodeSource किंवा nvm मधून Node 20+ install करा. node --version ने पडताळणी करा. अनेक Node आवृत्त्या install असतील, तर which node नवीन आवृत्तीकडे निर्देश करते आणि /usr/bin/node कडे नाही हे तपासा.

npm error code EACCES / permission denied, mkdir '/usr/lib/node_modules/...'. root-owned prefix मध्ये global install केले आहे. sudo वापरू नका. npm config set prefix ~/.npm-global सेट करा, ~/.npm-global/bin ला PATH मध्ये जोडा आणि नेहमीच्या user म्हणून पुन्हा install करा. आधीच्या sudo npm मुळे root-owned cache files (Your cache folder contains root-owned files) राहिल्या असतील, तर sudo chown -R $(id -u):$(id -g) ~/.npm चालवा.

Failed to open browser, अडकणारा login किंवा पोहोचता न येणारा redirect_uri=http://localhost:PORT. OAuth flow ला server वर उपलब्ध नसलेला browser आवश्यक आहे. तसेच त्याचा localhost callback तुमच्या laptop ऐवजी server कडे निर्देश करतो. API-key path (GEMINI_API_KEY) वापरा किंवा OAUTH_CALLBACK_PORT pin करा. ssh -L वापरून ते SSH वर forward करा आणि URL स्थानिक पातळीवर उघडा.

SSH disconnect झाल्यावर process नाहीसा झाला. तुम्ही gemini थेट SSH shell मधून चालवला. त्यामुळे तो त्या shell चा child होता आणि disconnect झाल्यावर pty सोबत बंद झाला. Recover करण्यासाठी काहीही नाही. प्रत्येक session tmux new -A -s gemini ने सुरू करा आणि CLI त्याच्या आत चालवा.

Key सेट केलेली असूनही auth अपयशी ठरते, CLI auth picker कडे परत जाते किंवा request मध्ये HTTP 400 सह API key not valid मिळते. CLI पाहत असलेल्या environment मध्ये key उपलब्ध नाही. printenv GEMINI_API_KEY ने पडताळणी करा. ते रिकामे असल्यास तुमचे ~/.gemini_env कधीही sourced झालेले नाही. ते ~/.bashrc मध्ये आहे का ते तपासा. Interactive shells, त्यात tmux देखील समाविष्ट आहे, ही file वाचतात; परंतु cron आणि इतर non-interactive shells ती वाचत नाहीत. Key value मध्ये असलेली अनावश्यक space किंवा quote देखील API key not valid निर्माण करू शकते.

429 / RESOURCE_EXHAUSTED / rate-limit message. Auth ज्या tier वर वापरते त्याची quota संपली आहे. Window reset होईपर्यंत प्रतीक्षा करा, agent ची गती कमी करा किंवा billed API key वापरा. Retry loop मध्ये अडकलेला agent हा संदेश पुन्हा पुन्हा निर्माण करत राहतो. तो थांबवा आणि तो काय करत आहे ते तपासा.

FAQ

Gemini CLI ला headless सर्व्हरवर authenticate कसे करावे?

Browser login ऐवजी API key वापरा. Google AI Studio मध्ये key तयार करा आणि ती तुमच्या shell कडून source केल्या जाणाऱ्या mode-600 फाइलमध्ये ठेवा (export GEMINI_API_KEY=...). त्यामुळे CLI OAuth browser flow पूर्णपणे वगळतो. तुम्हाला personal-account free tier वापरायचा असल्यास, OAUTH_CALLBACK_PORT=8085 वापरून loopback port निश्चित करा, ssh -L 8085:localhost:8085 user@server वापरून तो तुमच्या laptop कडे forward करा आणि दाखवलेली URL स्थानिक पातळीवर उघडा. मात्र यासाठी browser समोर तुमची उपस्थिती आवश्यक असते. त्यामुळे scripts साठी हा पर्याय योग्य नाही.

npm global install ला sudo का हवे असते आणि ते कसे टाळावे?

कारण npm चा default global prefix /usr/lib/node_modules आहे. त्यावर तुमचा user write करू शकत नाही. त्यामुळे साधा npm install -g हा command EACCES सह fail होतो. sudo npm -g हा चुकीचा उपाय आहे. त्यामुळे root-owned files तयार होतात आणि पुढील installs अयशस्वी होतात. योग्य उपाय म्हणजे prefix तुमच्या home कडे (npm config set prefix ~/.npm-global) निर्देशित करणे आणि त्याचा bin, PATH मध्ये add करणे. किंवा nvm वापरा. nvm global packages तुमच्या home अंतर्गत आपोआप install करतो.

disconnect केल्यानंतर Gemini CLI चालू कसे ठेवावे?

ते tmux मध्ये चालवा. तुमच्या SSH shell मधून सुरू केलेली process connection तुटल्यावर बंद होते, कारण ती त्या shell ची child process असते. tmux shell ला detached server अंतर्गत चालवतो. त्यामुळे disconnect झाल्यानंतरही ती process सुरू राहते. tmux new -A -s gemini वापरा आणि त्यामध्ये gemini चालवा. Ctrl-b d वापरून detach करा. नंतर tmux attach -t gemini वापरून पुन्हा attach करा.

production box वर Gemini CLI चालवणे सुरक्षित आहे का?

फक्त काळजीपूर्वक चालवले तर. Shell access असलेला agent त्याच्या user ला उपलब्ध असलेली कोणतीही कृती करू शकतो. तो dedicated unprivileged user म्हणून चालवा. त्या user कडे sudo अधिकार नसावेत. Production credentials मशीनवर ठेवू नका. --yolo auto-approval टाळा. Tool calls ला host पासून वेगळे ठेवण्यासाठी --sandbox (Docker किंवा Podman) वापरा. कोणताही एक flag सेट करण्यापेक्षा process ज्या account अंतर्गत चालते ते अधिक महत्त्वाचे आहे.

Gemini CLI साठी firewall ports उघडणे आवश्यक आहे का?

नाही. हे Google's APIs कडे outbound HTTPS calls करणारे client आहे. त्यामुळे त्याला outbound port 443 आवश्यक आहे; inbound ports आवश्यक नाहीत. OAuth tunnel वापरत असल्यास, निश्चित केलेला callback port (उदाहरणार्थ 8085) localhost वर असतो आणि तुमच्या SSH forward द्वारे त्याच्यापर्यंत पोहोचले जाते. तो open inbound port नसतो. Inbound access प्रतिबंधित ठेवा.