Jinsi ya kuendesha Gemini CLI kwenye VPS bila kivinjari

Unachojenga

Gemini CLI inayofanya kazi muda wote kwenye seva unayomiliki, inayoweza kufikiwa kupitia SSH, inayotekeleza kazi ndefu za wakala ambazo huendelea kufanya kazi hata baada ya kufunga kompyuta yako. Ufungaji wake unahitaji amri tatu pekee. Kazi kubwa inakuja pale unapotumia mbinu za kawaida za desktop: CLI ya Google inataka kufungua kivinjari ili kukuwezesha kuingia (login), na seva yako haina kivinjari. Kwa hivyo, sehemu kubwa ya mwongozo huu inahusu mbinu ya headless, kusakinisha toleo la sasa la Node ambalo distro yako haitakupa, kusakinisha npm kwa kiwango cha kimataifa (global) bila kuhitaji root, uthibitishaji bila kivinjari kwa kutumia API key unayoiweka mbali na historia ya shell yako, na kutumia tmux ili muunganisho wa SSH ukikatika, kazi inayoendelea isipotee.

Gemini CLI ni programu ya Node iliyo wazi (Apache-2.0) (@google/gemini-cli) inayowasiliana na mifano ya Gemini ya Google na ina uwezo wa kusoma na kuandika faili, kutekeleza amri za shell, na kuendesha zana katika saraka ya kazi. Kwenye VPS, hii ni wakala mdogo, inayopatikana muda wote ambayo unaweza kuiacha ikifanya kazi, ndiyo maana akaunti inayoiendesha, na vitambulisho vilivyopo kwenye seva hiyo, ni muhimu zaidi kuliko mpangilio wowote mmoja hapa.

Mahitaji ya awali na changamoto za kawaida

• VPS ya Ubuntu 24.04 KVM iliyo safi ikiwa na ufikiaji wa root au sudo. Mpango wowote wa KVM unafaa; CLI yenyewe ni nyepesi, inatumia MB chache za RAM ikiwa haitumiki.
• Node.js 20 au toleo jipya zaidi. Hili ndilo hitaji la msingi la toleo, na kifurushi cha distro kiko chini ya hili, angalia sehemu inayofuata.
• HTTPS ya kutoka (port 443) kuelekea API za Google. Hakuna port za kuingia zinazohitajika; hii ni mteja, si seva, kwa hivyo hufungui shimo lolote la firewall kwa ajili yake.
• Njia ya kujitambulisha (authenticate) isiyohitaji kivinjari kwenye seva: aidha Gemini API key kutoka Google AI Studio, au SSH tunnel inayorudi kwenye kivinjari cha mashine yako. Njia ya API-key ndiyo inayofaa kwa hati (scripts) na uendeshaji usio na usimamizi.
• Docker au Podman, ikiwa tu unataka --sandbox isolation. Ni hiari, imeelezwa karibu na mwisho.

Changamoto inayowakuta wengi: mtiririko wa kuingia wa mara ya kwanza wa gemini umejengwa kwa ajili ya desktop. Hujaribu kufungua kivinjari na, kwenye mashine isiyo na kiolesura (headless), aidha hushindwa au hukupa kiungo kisichofanya kazi. Amua njia ya uthibitishaji kabla ya kuanza.

Kumbuka: kifurushi cha distro ni cha zamani sana

Ubuntu 24.04 inatoa Node 18.19.1 katika hazina zake (repositories), ikiwa imeoanishwa na npm 9.2.0. package.json ya Gemini CLI inatangaza engines: { node: ">=20" }, na npm haisimamishi mchakato kwa sababu ya kutolingana kwa matoleo, inasakinisha hata hivyo na kuchapisha onyo linaloonyesha pengo hilo:

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 }

Ukipuuza onyo hilo, CLI itafanya kazi kwenye runtime isiyotumika, ambapo itafanya kazi vibaya au kuacha kufanya kazi mara tu inapokutana na API ya Node 20+ ambayo inatarajia kuwepo. Node 18 pia ilifikia mwisho wa maisha yake (end-of-life) mnamo Aprili 2025, kwa hivyo ni njia isiyo na matokeo mazuri. Sakinisha toleo la sasa la LTS kabla ya kusakinisha CLI. Njia mbili safi ni NodeSource (repo ya apt iliyosainiwa kwa ajili ya mfumo mzima) au nvm (kidhibiti cha matoleo kwa kila mtumiaji). Chagua moja.

NodeSource, ikiwa unataka Node ipatikane kwa kila mtumiaji kwenye seva:

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 lazima ichapishe v20.x au zaidi, v24.x ndiyo LTS inayotumika sasa. Angalia ukurasa wa NodeSource kwa hati ya usanidi ya sasa; setup_24.x katika URL ndiyo sehemu ya kubadilisha wakati LTS mpya inapotoka.

nvm, ikiwa ungependelea kuweka Node ndani ya folda ya nyumbani (home) ya mtumiaji mmoja na usiwahi kuigusa kwa sudo:

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

v0.40.1 katika URL hiyo ilikuwa ya sasa wakati mwongozo huu ukiandikwa; angalia README ya nvm kwa toleo la hivi karibuni na ubadilishe toleo hilo kabla ya kuliendesha. nvm ina faida kubwa kwa kazi hii: inasakinisha Node na vifurushi vyake vya kimataifa (global packages) chini ya ~/.nvm, kwa hivyo tatizo la ruhusa ya usakinishaji wa kimataifa katika sehemu inayofuata halitokei kamwe. Ukichagua njia ya nvm, unaweza kuruka hatua ya npm-prefix.

Kusakinisha CLI bila sudo npm -g

Amri inayovutia ni sudo npm install -g @google/gemini-cli. Usiitumie. Prefix ya kimataifa inayomilikiwa na root husababisha makosa ya ruhusa (permission errors) katika kila usakinishaji wa baadaye na huacha faili zinazomilikiwa na root kwenye npm cache yako ambazo zitaleta shida miezi ijayo. Endesha npm install -g ya kawaida (bila sudo) dhidi ya Node ya mfumo na utapata hitilafu nyingine:

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'

Hiyo ni npm ikijaribu kuandika kwenye /usr/lib, ambayo mtumiaji wako hana ruhusa nayo. Suluhisho si sudo, bali ni kuelekeza prefix ya kimataifa ya npm kwenye saraka yako ya nyumbani (home directory) ili usakinishaji wa kimataifa utue mahali unapomiliki:

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, si ~/.profile, imewekwa kwa makusudi: tmux, ambayo utaiendesha CLI ndani yake baada ya sehemu mbili kuanzia sasa, huanzisha shell isiyo ya kuingia (non-login shell) inayosoma ~/.bashrc na kuruka ~/.profile, kwa hivyo mstari wa PATH katika faili isiyo sahihi utafanya gemini isionekane mahali hasa unapoihitaji. gemini --version kuchapisha namba ya toleo ndiyo jaribio zima. Ikiwa badala yake utapata gemini: command not found, export yako ya PATH haikufanikiwa, angalia njia za kushindwa (failure modes). Kwenye nvm, ruka mistari ya prefix kabisa: tayari inasakinisha vitu vya kimataifa chini ya saraka yako ya nyumbani.

Ikiwa uliendesha sudo npm wakati fulani uliopita na sasa unaona Your cache folder contains root-owned files, irekebishe mara moja kwa sudo chown -R $(id -u):$(id -g) ~/.npm.

Tatizo la uthibitishaji wa headless, na jinsi ya kulitatua

Endesha gemini kwa njia ya mwingiliano (interactive) mara ya kwanza na itakupa chaguo la kuingia kwa kutumia akaunti yako ya Google. Kwenye desktop, hii hufungua tab ya kivinjari. Kwenye VPS isiyo na kiolesura (headless), hakuna kivinjari, kwa hivyo mchakato huu ama huchapisha URL ya localhost inayotarajia uifungue, au inafeli moja kwa moja na ujumbe kama huu:

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

Mtego hapa ni redirect_uri=http://localhost:PORT. Hata ukifungua URL hiyo kwenye laptop yako na kuidhinisha, Google huelekeza kwenye http://localhost:PORT, localhost iliyopo kwenye seva, port ambayo hakuna kitu kwenye laptop yako kinachoweza kuifikia. Uingiaji haukamiliki kamwe.

Kuna njia mbili sahihi za kulitatua.

Njia ya kwanza ni kutumia API key, na hii ndiyo chaguo bora kwa seva. Tengeneza key katika Google AI Studio (aistudio.google.com) na uipe CLI kama environment variable; inasoma GEMINI_API_KEY na kuruka kabisa mchakato wa kivinjari. Sasa, kuhusu sehemu ya "iweke mbali na historia na faili zinazoweza kusomwa na wote". Usichape export GEMINI_API_KEY=AIza... kwenye prompt, kwani itaingia kwenye ~/.bash_history ikiwa wazi (cleartext), na usiiweke kwenye faili ambayo wengine wanaweza kuisoma. Iandike kwenye faili yenye mode-600 ambayo shell inaisoma wakati wa kuanza:

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 inamaanisha ni mtumiaji wako pekee anayeweza kusoma faili hiyo. Thibitisha kuwa key imefika kwenye environment kwa kutumia printenv GEMINI_API_KEY; kama haichapishi chochote, CLI itarudi kwenye mchakato wa kivinjari na kufeli. Pia inasoma faili ya .env iliyopo kwenye ~/.gemini/ kama unapendelea mpangilio huo, kwa sheria ileile, kwa hivyo chmod 600 ~/.gemini/.env.

Njia ya pili inadumisha uingiaji wa akaunti binafsi ya Google (pamoja na tier yake ya bure) kwa kutumia tunnel ya OAuth callback kurudi kwenye laptop yako. Changamoto ni kwamba loopback server ya CLI huchagua port ya nasibu kila inapoendeshwa, kwa hivyo hakuna kitu thabiti cha kufoward isipokuwa ukiifunga (pin) kwanza kwa kutumia environment variable ya OAUTH_CALLBACK_PORT, kisha u-forward port hiyo husika:

# 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 haiwezi kufungua kivinjari, kwa hivyo inachapisha URL ya uthibitishaji; ifungue kwenye kivinjari cha laptop yako, idhinishe, na Google inapoelekeza kwenye http://localhost:8085/..., SSH forward itaipeleka kwenye loopback server iliyo kwenye VPS na uingiaji utakamilika. Ukiacha port bila kuifunga, itatua kwenye port mpya ya nasibu kila unapoendesha, ambayo hakuna ssh -L iliyowekwa mapema inayoweza kuikamata. Inafanya kazi, lakini inahitaji uwe umekaa mbele ya kivinjari, kwa hivyo haifai kwa hati (scripts). Kwa chochote unachokiacha kikiendelea kufanya kazi, tumia API key.

Kwa Vertex AI au mradi wa Google Cloud badala ya AI Studio, weka GOOGLE_API_KEY pamoja na GOOGLE_GENAI_USE_VERTEXAI=true, au GOOGLE_CLOUD_PROJECT kwa leseni ya Code Assist, kwa kufuata nidhamu ileile ya environment-variable na faili ya mode-600.

Iendeshe ndani ya tmux ili session ya SSH iliyokatika isiiue

Mchakato wa gemini unaouanzisha moja kwa moja kutoka kwenye shell yako ya SSH ni mtoto wa shell hiyo. Ukipoteza muunganisho, laptop ikizimika, Wi-Fi ikikatika, au muda wa idle ukiisha, sshd huvunja pseudo-terminal, shell hupokea SIGHUP, na nayo hukata muunganisho wa CLI. Kazi inayochukua dakika kumi kuhariri faili hufa pamoja nayo, na ukirejea hakuna mchakato wa kuendeleza kazi hiyo.

tmux hutatua hili kwa kumiliki shell badala ya sshd kuimiliki. Hii ni kanuni sawa na kuendesha AI coding agent kwenye VPS ya mbali ndani ya tmux, na inafanya kazi vivyo hivyo hapa:

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 huunganisha kwenye session yenye jina gemini ikiwa ipo, na huitengeneza ikiwa haipo; kwa hivyo huu ndio amri moja ya kuendesha mara tu baada ya kila login. Shell iliyo ndani inamilikiwa na tmux server iliyotengwa, si na session yako ya SSH, kwa hivyo kukatika kwa muunganisho hakuathiri CLI inayoendelea kufanya kazi. Unganisha tena, fanya attach, na utarejea kwenye scrollback ileile. Ikiwa utaishia kuendesha session kadhaa za agent kwenye mashine moja, moja kwa kila tmux session, hazina njia ya kuwasiliana hapa, tofauti na Claude Code, ambapo session moja inaweza kupitisha maandishi kwa nyingine kwenye VPS ileile, kwa hivyo iweke kila kazi ya Gemini iwe huru au uziratibu kupitia faili zilizopo kwenye diski.

Kwa uendeshaji usio wa maingiliano (non-interactive) na wa kiskripti, Gemini CLI ina hali ya headless: gemini -p "summarise the failing tests in this repo" huchapisha jibu na kutoka, na --output-format json hutoa matokeo yanayoweza kusomwa na mashine ili kupelekwa kwingine. Hali ya headless yenye API key ndiyo hasa unayohitaji ndani ya tmux session inayoendesha batch job ndefu, au inayozinduliwa kutoka kwenye cron entry, kwa tahadhari moja: cron job haisomi faili zako za login, kwa hivyo ipe mstari wa crontab GEMINI_API_KEY yake yenyewe (au fanya amri isome ~/.gemini_env), vinginevyo CLI itajaribu kutumia mtiririko wa kivinjari na kufeli.

Sandboxing na ruhusa kwenye seva inayotumika kwa uzalishaji (production)

Wakala mwenye uwezo wa kufikia shell ni shell yenyewe. Gemini CLI inaweza kuendesha amri, na kwa chaguomsingi huomba idhini kabla ya kila amri hatari, lakini watu hutumia --yolo (kuidhinisha kila zana kiotomatiki). Hapo, inaweza kufuta faili, kufanya push kwenye git, au kufikia huduma za ndani kwa mamlaka kamili ya mtumiaji anayeiendesha. Kwenye seva inayotumika kwa uzalishaji, hii ni hatari ya kweli, si nadharia.

Kuna vidhibiti vitatu, kulingana na faida unayopata:

• Iendeshe kama mtumiaji maalum asiye na upendeleo (unprivileged user). Si root, na si mwanachama wa sudo. Unda mtumiaji wa agent mwenye home directory yake, sakinisha Node na CLI huko. Maelekezo yaliyofasiriwa vibaya yatabaki ndani ya akaunti hiyo pekee. Hili ndilo uamuzi wenye thamani kubwa zaidi.
• Weka vitambulisho vya uzalishaji (production credentials) mbali na seva hiyo. Usiweke ~/.aws/credentials ya uzalishaji, usinakili .env kutoka kwenye seva ya uzalishaji, na usitumie nenosiri la database lenye ruhusa ya kuandika kwenye kitu chochote muhimu. Ipe kitambulisho cha staging au cha kusoma pekee (read-only).
• Tumia sandbox iliyojengwa ndani. Ukiwa na Docker au Podman, gemini --sandbox (au GEMINI_SANDBOX=docker) huendesha zana za wakala ndani ya container iliyotengwa na mfumo wa faili wa host na mtandao. Hii si mbadala wa mtumiaji asiye na upendeleo, lakini ni safu ya pili imara wakati VPS hiyo hiyo inafanya kazi halisi.

Ikiwa unaendesha Gemini CLI pamoja na zana nyingine za kujihostia, kama vile MCP server inayofungua zana kwa wakala kwenye VPS hiyo hiyo, chukulia kila uwezo ulioongezwa kama sehemu nyingine ambayo wakala anaweza kuifikia. Punguza wigo wa token unazompa ili zifanye kazi moja tu maalum.

Quota, gharama, na njia ya uthibitishaji uliyochagua

Njia ya uthibitishaji (auth path) huamua jinsi unavyotozwa gharama. Akaunti binafsi ya Google (njia ya OAuth) hutumia tier ya bure ya Gemini Code Assist, ikiwa na vikomo halisi kwa dakika na kwa siku; ukivuka vikomo hivyo, maombi yataleta hitilafu ya rate-limit hadi muda wa mapumziko utakapokwisha. API key kutoka AI Studio inaweza kuwa ya tier ya bure au ya kulipia kulingana na mradi; key ya kulipia huongeza vikomo na kutoza gharama kwa kila token. Uthibitishaji wa Vertex na Cloud-project hutoza gharama kupitia Google Cloud.

Mambo mawili ya kuzingatia. Wakala anayefanya kazi bila kusimamiwa katika loop anaweza kumaliza quota haraka, kwa hivyo mfuatilie mara chache za kwanza kabla ya kumwamini kwenye cron job. Na ikiwa sababu yako ya kutumia model ya upande wa seva ni faragha au inference isiyo na kikomo badala ya kutumia models za Google, hiyo ni nyenzo tofauti; self-hosting an open LLM with Ollama on a VPS huweka weights na prompts kwenye seva yako mwenyewe, kwa gharama ya kutumia model ndogo zaidi kuliko Gemini.

Kuweka toleo la sasa

Gemini CLI hutoa matoleo mapya mara kwa mara. Kwa sababu uliisakinisha kwenye folda inayomilikiwa na mtumiaji, masasisho hayahitaji sudo:

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

Kuna njia za kupata matoleo: @latest ni toleo thabiti, @preview ni toleo la majaribio la kila wiki, @nightly ni toleo la kisasa zaidi, tumia @latest kwa huduma zozote unazozitegemea. Kwenye nvm, vifurushi vya kimataifa (global packages) hukaa chini ya toleo la Node linalotumika, kwa hivyo baada ya kutumia nvm use kubadili toleo la Node unaweza kuhitaji kusakinisha upya CLI. Soma maelezo ya toleo badala ya kufuatilia kila marekebisho madogo.

Njia za kufeli, pamoja na mifuatano kamili ya herufi

npm WARN EBADENGINE Unsupported engine ... required: { node: '>=20' }, kisha CLI kuacha kufanya kazi wakati wa runtime. Toleo la Node ni la zamani, distro inatumia 18.19.1, ambayo pia imepitwa na wakati. Sakinisha Node 20+ kutoka NodeSource au nvm, thibitisha kwa node --version, na ikiwa una matoleo kadhaa ya Node yaliyosakinishwa, hakikisha which node inaelekeza kwenye toleo jipya na si /usr/bin/node.

npm error code EACCES / permission denied, mkdir '/usr/lib/node_modules/...'. Usakinishaji wa kimataifa (global) kwenye prefix inayomilikiwa na root. Usitumie sudo, weka npm config set prefix ~/.npm-global, ongeza ~/.npm-global/bin kwenye PATH, na usakinishe upya kama mtumiaji wa kawaida. Ikiwa sudo npm ya awali iliacha faili za cache zinazomilikiwa na root (Your cache folder contains root-owned files), endesha sudo chown -R $(id -u):$(id -g) ~/.npm.

Failed to open browser, login inayokwama, au redirect_uri=http://localhost:PORT ambayo huwezi kuifikia. Mtiririko wa OAuth unahitaji kivinjari ambacho seva haina, na callback ya localhost inaelekeza kwenye seva, si kwenye laptop yako. Tumia njia ya API-key (GEMINI_API_KEY), au pini OAUTH_CALLBACK_PORT, ipeleke kupitia SSH kwa ssh -L, na ufungue URL hiyo ndani ya kompyuta yako.

Mchakato ulipotea wakati SSH ilipokatika. Uliendesha gemini moja kwa moja kutoka kwenye shell ya SSH, kwa hivyo ilikuwa mtoto wa shell hiyo na ilikufa pamoja na pty wakati wa kukatika kwa muunganisho. Hakuna cha kurejesha. Anza kila kikao na tmux new -A -s gemini na uendeshe CLI ndani yake.

Auth bado inafeli hata ufunguo ukiwa umewekwa, CLI inarudi kwenye kichagua auth, au ombi linarudisha API key not valid na HTTP 400. Ufunguo haupo kwenye mazingira (environment) ambayo CLI inaona. Thibitisha kwa printenv GEMINI_API_KEY; ikiwa ni tupu, ~/.gemini_env yako haikuwahi kusomwa (sourced), hakikisha mstari huo upo kwenye ~/.bashrc, ambayo shell shirikishi (pamoja na tmux) husoma lakini cron na shell nyingine zisizo shirikishi hazisomi. Nafasi ya ziada au alama ya kunukuu ndani ya thamani ya ufunguo pia husababisha API key not valid.

429 / RESOURCE_EXHAUSTED / ujumbe wa kikomo cha kasi (rate-limit). Umefikia kikomo cha quota kwa tier yoyote ambayo auth yako inatumia. Subiri dirisha hilo liweke upya, punguza kasi ya wakala (agent), au hamia kwenye API key ya kulipia. Wakala aliyekwama kwenye mzunguko wa kujaribu tena (retry loop) ataendelea kugonga kikomo hiki, msimamishe na uangalie anachofanya.

FAQ

Ninawezaje kuthibitisha Gemini CLI kwenye seva isiyo na kiolesura (headless)?

Tumia API key, usitumie kuingia kupitia kivinjari. Tengeneza key katika Google AI Studio, iweke kwenye faili lenye mode-600 ambalo shell yako inalisoma (export GEMINI_API_KEY=...), na CLI itaruka kabisa mchakato wa OAuth wa kivinjari. Ikiwa unataka hasa kutumia tier ya bure ya akaunti binafsi, funga loopback port kwa OAUTH_CALLBACK_PORT=8085, ipeleke kwenye laptop yako kwa ssh -L 8085:localhost:8085 user@server, na ufungue URL iliyoonyeshwa hapo ndani, lakini hii inahitaji uwepo wako kwenye kivinjari, kwa hivyo haifai kwa script.

Kwa nini npm global install inataka sudo, na ninawezaje kuiepuka?

Kwa sababu prefix ya kawaida ya npm ya global ni /usr/lib/node_modules, ambayo mtumiaji wako hawezi kuiandikia, kwa hivyo npm install -g ya kawaida inafeli kwa EACCES. Suluhisho lisilo sahihi ni sudo npm -g, ambalo huacha faili zinazomilikiwa na root na kuharibu usakinishaji wa baadaye. Suluhisho sahihi ni kuelekeza prefix kwenye home yako (npm config set prefix ~/.npm-global) na kuongeza bin yake kwenye PATH, au tumia nvm, ambayo husakinisha vifurushi vya global chini ya home yako moja kwa moja.

Ninawezaje kuifanya Gemini CLI iendelee kufanya kazi baada ya kukata muunganisho?

Iendeshe ndani ya tmux. Mchakato ulioanzishwa kutoka kwa SSH shell yako hufa wakati muunganisho unapokatika kwa sababu ni mtoto wa shell hiyo; tmux huendesha shell chini ya seva iliyotengwa ambayo huendelea kuwepo baada ya kukatika. Tumia tmux new -A -s gemini, endesha gemini ndani yake, jitenge na Ctrl-b d, na uunganishe tena baadaye kwa tmux attach -t gemini.

Je, ni salama kuendesha Gemini CLI kwenye mashine ya production?

Kwa uangalifu tu, kwa sababu wakala mwenye uwezo wa kufikia shell anaweza kufanya chochote ambacho mtumiaji anayeendesha anaweza kufanya. Iendeshe kama mtumiaji maalum asiye na upendeleo (unprivileged) bila sudo, weka vitambulisho vya production mbali na mashine hiyo, epuka --yolo ya kuidhinisha kiotomatiki, na tumia --sandbox (Docker au Podman) kutenga wito wa zana kutoka kwa host. Akaunti inayoiendesha ni muhimu zaidi kuliko flag yoyote unayoweka.

Je, ninahitaji kufungua port yoyote ya firewall kwa ajili ya Gemini CLI?

Hapana. Ni mteja anayefanya wito wa HTTPS kwenda nje kwenye API za Google, kwa hivyo inahitaji port 443 ya kwenda nje lakini hakuna port za kuingia ndani. Ikiwa unatumia tunnel ya OAuth, port ya callback iliyofungwa (kwa mfano 8085) hukaa kwenye localhost na hufikiwa kupitia SSH forward yako, si port iliyo wazi ya kuingia ndani. Weka milango ya kuingia ndani ikiwa imefungwa.