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

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

तुमच्या स्वतःच्या सर्व्हरवर एक नेहमी चालू राहणारे Gemini CLI, जे SSH द्वारे सुलभ आहे. लॅपटॉप बंद केल्यानंतरही हे CLI लांब चालणाऱ्या agent tasks पूर्ण करत राहील. याची installation फक्त तीन commands मध्ये पूर्ण होते. परंतु, डेस्कटॉपवर आधारित असलेल्या गोष्टींसाठी काही आव्हाने आहेत: Google च्या CLI ला login करण्यासाठी browser उघडण्याची गरज असते, पण तुमच्या server वर browser नाही. म्हणून, या मार्गदर्शिकेचा मोठा भाग headless पद्धतीवर आधारित आहे — ज्यामध्ये तुम्हाला distro कडून न मिळणारा एक नवीन Node, root परवान्याशिवाय global npm install, shell history मध्ये न येणाऱ्या API key द्वारे browserless auth, आणि tmux चा वापर समाविष्ट आहे, जेणेकरून SSH session तुटल्यास चालू असलेले task थांबणार नाही.

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

Prerequisites and the honest gotchas

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

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

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

Ubuntu 24.04 च्या स्वतःच्या repositories मध्ये Node 18.19.1 आणि npm 9.2.0 उपलब्ध आहे. Gemini CLI मध्ये package.json द्वारे engines: { node: ">=20" } घोषित केले आहे. npm बाय डिफॉल्ट mismatch असल्यास प्रक्रिया थांबवत नाही — ते सूचना (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 अशा runtime वर चालते जे supported नाही. जेव्हा CLI ला Node 20+ API ची आवश्यकता लागते, तेव्हा ते चुकीच्या पद्धतीने कार्य करते किंवा crash होते. Node 18 चे end-of-life April 2025 मध्ये झाले आहे, त्यामुळे ते वापरणे योग्य नाही. CLI इन्स्टॉल करण्या आधी सध्याचे LTS इन्स्टॉल करा. यासाठी दोन मार्ग आहेत: NodeSource (system-wide signed apt repo) किंवा nvm (per-user version manager). यापैकी एक निवडा.

जर तुम्हाला सर्व users साठी 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 हे हे लेखन करतानाचे व्हर्जन होते; नवीनतम release साठी nvm चे README तपासा आणि रन करण्यापूर्वी व्हर्जन बदला. nvm चा एक मोठा फायदा आहे: ते Node आणि त्याचे global packages ~/.nvm मध्ये इन्स्टॉल करते, त्यामुळे पुढील सेक्शनमधील global-install permission ची समस्या येत नाही. जर तुम्ही nvm वापरत असाल, तर तुम्ही npm-prefix स्टेप वगळू शकता.

sudo npm -g शिवाय CLI इंस्टॉल करा

sudo npm install -g @google/gemini-cli ही कमांड आकर्षक वाटते. परंतु ती वापरू नका. root-owned global prefix मुळे पुढील प्रत्येक install मध्ये permission errors येतात आणि npm cache मध्ये root-owned फाइल्स राहतात, ज्या भविष्यात समस्या निर्माण करतात. system Node वर साधी (no-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 मध्ये लिहिण्याचा प्रयत्न करत आहे, ज्यासाठी तुमच्याकडे परवानगी नाही. उपाय 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 नाही, हे मुद्दाम केले आहे: tmux — जे तुम्ही दोन विभागांनंतर CLI चालवण्यासाठी वापरणार आहात — एक non-login shell सुरू करते जे ~/.bashrc वाचते आणि ~/.profile वगळते, त्यामुळे चुकीच्या फाईलमध्ये असलेली PATH ओळ gemini ला अदृश्य करते. gemini --version द्वारे version number प्रिंट करणे हीच मुख्य चाचणी आहे. जर तुम्हाला gemini: command not found मिळाले, तर तुमची PATH export यशस्वी झाली नाही — failure modes पहा. nvm वापरत असल्यास, prefix च्या ओळी पूर्णपणे वगळा: ते आधीच globals तुमच्या home मध्ये इंस्टॉल करते.

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

headless auth समस्या आणि त्यावर मात कशी करावी

पहिल्यांदा gemini interactively चालवल्यास, ते तुम्हाला Google account ने log in करण्याचा पर्याय देते. Desktop वर हे एक browser tab उघडते. Headless VPS वर browser नसतो, त्यामुळे प्रक्रिया एक localhost URL प्रिंट करते (जे तुम्हाला उघडायचे असते) किंवा खालीलप्रमाणे error देते:

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 मुळे ही अडचण येते. तुम्ही तुमच्या laptop वर ती URL उघडून approve केली तरी, Google http://localhost:PORT वर redirect करते — जे server वरील localhost आहे, आणि तुमच्या laptop वरून त्या port ला access करता येत नाही. त्यामुळे login पूर्ण होत नाही.

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

पहिला मार्ग म्हणजे API key, जो server साठी योग्य पर्याय आहे. Google AI Studio (aistudio.google.com) मध्ये key तयार करा आणि ती CLI ला environment variable म्हणून द्या; यामुळे GEMINI_API_KEY वाचले जाते आणि browser flow पूर्णपणे skip होतो. आता "key ला history आणि world-readable files पासून सुरक्षित ठेवणे" या गोष्टीकडे लक्ष द्या. prompt वर export GEMINI_API_KEY=AIza... टाईप करू नका — ते ~/.bash_history मध्ये cleartext मध्ये साठवले जाते, आणि ती key अशा फाईलमध्ये ठेवू नका जी इतर कोणीही वाचू शकते. ती key एका mode-600 फाईलमध्ये लिहा, जी shell सुरुवातीला source करेल:

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 ती फाईल वाचू शकतो. printenv GEMINI_API_KEY वापरून key environment मध्ये पोहोचली आहे की नाही याची खात्री करा; जर काहीही print झाले नाही, तर CLI पुन्हा browser flow वापरण्याचा प्रयत्न करेल आणि fail होईल. जर तुम्हाला ~/.gemini/ मध्ये .env फाईल वापरायची असेल, तर ते देखील शक्य आहे — पण नियम तोच आहे, म्हणजेच chmod 600 ~/.gemini/.env.

दुसरा मार्ग म्हणजे OAuth callback ला तुमच्या laptop कडे tunnel करणे, ज्यामुळे personal-Google-account login (आणि त्याचा free tier) वापरता येतो. अडचण अशी आहे की CLI चा loopback server प्रत्येक वेळी एक random port वापरतो, त्यामुळे port स्थिर नसतो. जोपर्यंत तुम्ही OAUTH_CALLBACK_PORT environment variable वापरून तो port fix करत नाही, तोपर्यंत forwarding करणे शक्य नाही; त्यानंतर तोच 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 प्रिंट करते; ती तुमच्या laptop च्या browser मध्ये उघडा, approve करा, आणि जेव्हा Google http://localhost:8085/... वर redirect करेल, तेव्हा SSH forwarding मुळे ते VPS वरील loopback server कडे पोहोचेल आणि login पूर्ण होईल. जर port fix केला नाही, तर प्रत्येक वेळी तो नवीन random port वर जाईल, जो आधीपासून सेट केलेल्या कोणत्याही ssh -L द्वारे पकडता येणार नाही. ही पद्धत काम करते, पण त्यासाठी तुम्हाला browser समोर बसून राहावे लागते, म्हणून scripts साठी ही पद्धत योग्य नाही. सतत चालू राहणाऱ्या (running) कामांसाठी API key वापरा.

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

SSH session डिस्कनेक्ट झाली तरी प्रक्रिया चालू ठेवण्यासाठी tmux वापरा

तुम्ही SSH shell मधून थेट सुरू केलेली gemini प्रक्रिया त्या shell ची child process असते. जर कनेक्शन तुटले — जसे की laptop बंद होणे, Wi-Fi डिस्कनेक्ट होणे किंवा idle timeout होणे — तर sshd pseudo-terminal बंद करते. यामुळे shell ला SIGHUP मिळतो आणि CLI बंद होते. फाईल्स एडिट करताना 10 मिनिटांनंतर एखादे काम सुरू असताना कनेक्शन तुटल्यास, ते काम थांबते आणि पुन्हा reconnect केल्यावर ती process रिकव्हर करता येत नाही.

tmux ही समस्या सोडवते कारण ते shell च्या मालकीचे असते, sshd च्या नाही. ही पद्धत remote VPS वर tmux मध्ये AI coding agent चालवण्या(https://example.com) सारखीच आहे आणि येथेही तशीच काम करते:

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

जर gemini नावाचे session अस्तित्वात असेल तर tmux new -A -s gemini त्याला attach करते, अन्यथा ते नवीन session तयार करते. त्यामुळे प्रत्येक login नंतर ही एकच कमांड चालवणे आवश्यक आहे. यातील shell हे detached tmux server चे असते, तुमच्या SSH session चे नाही. त्यामुळे कनेक्शन तुटले तरी CLI चालू राहते. पुन्हा reconnect करा, attach करा आणि तुम्ही त्याच scrollback मध्ये परत याल.

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

Production चालवणाऱ्या बॉक्सवरील Sandboxing आणि permissions

ज्या agent कडे shell access आहे, तो एक shell आहे. Gemini CLI commands रन करू शकते आणि डीफॉल्टनुसार प्रत्येक जोखमीच्या command साठी ते विचारते — परंतु लोक --yolo (प्रत्येक tool call ला auto-approve करणे) वापरतात, ज्यामुळे ते files डिलीट करू शकते, git वर push करू शकते किंवा ज्या user ने ते रन केले आहे त्याच्या पूर्ण अधिकाराने internal services ला कॉल करू शकते. ज्या box वर production देखील चालते, तिथे हा धोका केवळ काल्पनिक नसून प्रत्यक्ष आहे.

तीन नियंत्रणे (controls), त्यांच्या प्रभावाच्या क्रमानुसार:

• Dedicated, unprivileged user म्हणून रन करा. root किंवा sudo चा सदस्य नको. स्वतःच्या home directory सह एक agent user तयार करा, तिथे Node आणि CLI इंस्टॉल करा; यामुळे चुकीच्या सूचना केवळ त्याच account पर्यंत मर्यादित राहतील. हा सर्वात महत्त्वाचा निर्णय आहे.
• Production credentials त्या box वर ठेवू नका. कोणतेही prod ~/.aws/credentials, production मधून कॉपी केलेले .env, किंवा महत्त्वाच्या गोष्टींवर write access असलेले database passwords नकोत. त्याऐवजी staging किंवा read-only credentials वापरा.
• Built-in sandbox वापरा. Docker किंवा Podman इंस्टॉल असल्यास, gemini --sandbox (किंवा GEMINI_SANDBOX=docker) agent चे tool calls host filesystem आणि network पासून वेगळ्या असलेल्या container मध्ये रन करते. हे unprivileged user ला पर्याय नाही, परंतु जेव्हा तोच VPS प्रत्यक्ष कामासाठी वापरला जातो, तेव्हा हे एक मजबूत दुसरे layer आहे.

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

Quota, cost, आणि तुम्ही निवडलेला auth path

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

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

अपडेटेड ठेवणे

Gemini CLI चे नवीन व्हर्जन वारंवार येते. तुम्ही ते user-owned prefix मध्ये इंस्टॉल केले असल्यामुळे, अपडेटसाठी कधीही sudo ची गरज पडणार नाही:

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

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

Failure modes, with the exact strings

npm WARN EBADENGINE Unsupported engine ... required: { node: '>=20' }, आणि नंतर runtime ला CLI crash होणे. Node खूप जुने आहे — distro चे version 18.19.1 आहे, जे end-of-life च्या पलीकडे आहे. NodeSource किंवा nvm मधून Node 20+ इंस्टॉल करा, node --version ने खात्री करा, आणि जर तुमच्याकडे अनेक Nodes इंस्टॉल असतील, तर which node नवीन version कडे आणि /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 सेट करा, PATH वर ~/.npm-global/bin ठेवा, आणि तुमच्या सामान्य user ने पुन्हा इंस्टॉल करा. जर आधीच्या 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, लॉगिन हँग होणे, किंवा redirect_uri=http://localhost:PORT ज्यापर्यंत तुम्ही पोहोचू शकत नाही. OAuth flow ला ब्राउझरची आवश्यकता असते जो सर्व्हरवर उपलब्ध नाही, आणि त्याचा localhost callback सर्व्हरकडे निर्देशित होतो, तुमच्या laptop कडे नाही. API-key मार्ग (GEMINI_API_KEY) वापरा, किंवा OAUTH_CALLBACK_PORT पिन करा, ssh -L द्वारे SSH वरून forward करा, आणि URL स्थानिक पातळीवर (locally) उघडा.

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

Key सेट असूनही Auth फेल होत आहे — CLI पुन्हा auth picker वर येते, किंवा request मध्ये HTTP 400 सह API key not valid मिळते. Key, CLI ला दिसणाऱ्या environment मध्ये नाहीये. printenv GEMINI_API_KEY ने खात्री करा; जर ते रिकामे असेल, तर तुमची ~/.gemini_env कधीच source झाली नव्हती — ~/.bashrc मध्ये ती line आहे की नाही ते तपासा; interactive shells (tmux सह) ती वाचतात पण 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

headless server वर Gemini CLI 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 pin करा, ssh -L 8085:localhost:8085 user@server वापरून तो तुमच्या laptop वर forward करा, आणि स्थानिक पातळीवर (locally) printed URL उघडा — परंतु यासाठी browser मध्ये उपस्थित राहणे आवश्यक आहे, म्हणून scripts साठी हे योग्य नाही.

npm global install साठी sudo का लागतो आणि ते कसे टाळायचे?

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

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

ते tmux मध्ये चालवा. SSH shell मधून सुरू झालेली process कनेक्शन तुटल्यावर बंद होते कारण ती त्या shell ची child process असते; 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) वापरा. तुम्ही सेट केलेल्या कोणत्याही single flag पेक्षा, ते कोणत्या account अंतर्गत चालते हे अधिक महत्त्वाचे आहे.

Gemini CLI साठी मला कोणतेही firewall ports उघडावे लागतील का?

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