להריץ Gemini CLI בשרת VPS ללא ממשק גרפי

מה אתם בונים

ממשק Gemini CLI הפועל תמיד (always-on) על שרת בבעלותכם, הנגיש באמצעות SSH, ומריץ משימות סוכן (agent) ארוכות הממשיכות לעבוד גם לאחר סגירת המחשב הנייד. ההתקנה כוללת שלוש פקודات. החלק המורכב הוא כל מה שדורש ממשק גרפי (desktop): ה-CLI של Google מנסה לפתוח דפדפן לצורך התחברות, ולשרת שלכם אין דפדפן. לכן, רוב המדריך מתמקד בשיטת headless — גרסת Node עדכנית שההפצה (distro) לא מספקת, התקנת npm גלובלית שאינה דורשת root, אימות ללא דפדפן (browserless) באמצעות מפתח API ששומרים מחוץ להיסטוריית ה-shell, ושימוש ב-tmux כדי שניתוק של חיבור SSH לא יפסיק משימה רצה.

Gemini CLI היא תוכנת Node בקוד פתוח (Apache-2.0) (@google/gemini-cli) המתקשרת עם מודלי Gemini של Google. היא מסוגלת לקרוא ולכתוב קבצים, להריץ פקודות shell ולהפעיל כלים בספרייה העובדת (working directory). בשרת VPS, היא משמשת כסוכן קטן הזמין תמיד ويمكن להשאיר אותו עובד — וזו הסיבה שחשובות יותר מכל הגדרה אחרת כאן, המשתמש שמריץ אותה והפרטי זיהוי (credentials) שנשמרים על המכונה.

דרישות קדם ומכשולים נפוצים

• שרת Ubuntu 24.04 KVM חדש עם הרשאות root או sudo. כל תוכנית KVM תתאים; ממשק ה-CLI עצמו קל וצורך כמה מאות MB של RAM במצב Idle.
• Node.js 20 ומעלה. זוהי מגבלת הגרסה המינימלית היחידה, וחבילת ההפצה (distro package) היא בגרסה נמוכה יותר — ראה את הסעיף הבא.
• גישת HTTPS (פורט 443) החוצה אל ה-APIs של Google. אין צורך בפורטים נכנסים (inbound); זוהי אפליקציית לקוח ולא שרת, לכן אין צורך לפתוח חור ב-firewall עבורה.
• שיטת אימות שאינה דורשת דפדפן בשרת: או Gemini API key מ-Google AI Studio, או SSH tunnel חזרה לדפדפן במחשב האישי שלך. שימוש ב-API-key הוא המתאים ביותר עבור סקריפטים והרצות אוטונומיות.
• Docker או Podman, רק אם ברצונך להשתמש ב---sandbox isolation. אופציונלי, מפורט לקראת הסוף.

המכשול שנתקע בו כולם: תהליך ההתחברות הראשון של gemini מיועד לממשק שולחני (desktop). הוא מנסה לפתוח דפדפן, ובמערכת ללא ממשק גרפי (headless), הוא ייכשל או יספק קישור שאינו עובד. יש להחליט על שיטת האימות לפני תחילת העבודה.

Node: חבילת ההפצה ישנה מדי

Ubuntu 24.04 מספקת את Node 18.19.1 מהמאגרים שלה, יחד עם npm 9.2.0. ה-package.json של Gemini CLI מגדיר את engines: { node: ">=20" }, ו-npm אינו עוצר את התהליך כברירת מחדל במקרה של חוסר התאמה — הוא מתקין בכל זאת ומציג אזהרה המציינת את הפער:

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 ירוץ על סביבת זמן (runtime) שאינה נתמכת. במצב זה, ה-CLI יתנהג בצורה לא תקינה או יקרוס ברגע שינסה להשתמש ב-API של Node 20 ומעלה. בנוסף, התמיכה ב-Node 18 הסתיימה באפריל 2025, ולכן זו אינה אפשרות תקינה. יש להתקין גרסת LTS עדכנית לפני התקנת ה-CLI. שתי הדרכים המומלצות הן 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 את סكريפט ההתקנה העדכני; יש לעדכן את ה-setup_24.x בכתובת ה-URL כאשר יוצאת גרסת 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

הגרסה v0.40.1 בכתובת ה-URL הייתה העדכנית בזמן כתיבת המדריך; בדקו ב-README של nvm את הגרסה האחרונה והחליפו את מספר הגרסה לפני ההרצה. ל-nvm יש יתרון משמעותי למשימה זו: הוא מתקין את Node ואת החבילות הגלובליות שלו תחת ~/.nvm, ולכן בעיית הרשאות ההתקנה הגלובלית בסעיף הבא לא תתרחש. אם תבחרו בדרך של nvm, ניתן לדלג על שלב ה-npm-prefix.

התקנת ה-CLI ללא sudo npm -g

הפקודה המפתה היא sudo npm install -g @google/gemini-cli. אל תשתמש בה. שימוש ב-global prefix בבעלות root יגרום לשגיאות הרשאה בכל התקנה עתידית, וישאיר קבצים בבעלות root בתוך ה-npm cache, מה שיגרום לבעיות בעתיד. הרצת npm install -g רגיל (ללא sudo) מול Node של המערכת תגרום לשגיאה הבאה:

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 — יש להפנות את ה-global prefix של npm לתיקיית הבית שלך, כך שהתקנות גלובליות יישמרו במקום שבו יש לך בעלות:

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, סימן ש-export של PATH לא נכנס — בדוק את אפשרויות הכשל. אם אתה משתמש ב-nvm, דלג על שורות ה-prefix לחלוטין: הוא כבר מתקין חבילות גלובליות תחת תיקיית הבית שלך.

אם הרצת sudo npm בשלב מוקדם יותר ומופיע כעת Your cache folder contains root-owned files, תקן זאת באמצעות sudo chown -R $(id -u):$(id -g) ~/.npm.

בעיית ה-auth בגרסת headless, ואיך לעקוף אותה

הרץ את gemini באופן אינטראקטיבי בפעם הראשונה והוא יציע לך להתחבר באמצעות חשבון ה-Google שלך. במחשב שולחני זה יפתח לשונית בדפדפן. ב-VPS במצב headless אין דפדפן, לכן התהליך יציג כתובת localhost שעליך לפתוח, או ייכשל עם שגיאה כזו:

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. גם אם תפתח את הכתובת הזו בלפטופ ותאשר אותה, Google תבצע הפניה ל-http://localhost:PORT — localhost על השרת, פורט ששום דבר מהלפטופ לא יכול להגיע אליו. ההתחברות לעולם לא תסתיים.

ישנן שתי דרכים תקינות לפתרון.

הראשונה היא שימוש ב-API key, וזו ברירת המחדל הנכונה עבור שרת. צור מפתח ב-Google AI Studio (aistudio.google.com) והעבר אותו ל-CLI כמשתנה סביבה; הוא קורא את GEMINI_API_KEY ומדלג על תהליך הדפדפן לחלוטין. כעת, בנוגע לחלק של "שמירה מחוץ להיסטוריה ומקבצים שניתנים לקריאה על ידי אחרים": אל תקליד את export GEMINI_API_KEY=AIza... בשורת הפקודה — הוא יישמר ב-~/.bash_history בפורמט cleartext, ואל תשים אותו בקובץ שמשתמשים אחרים יכולים לקרוא. כתוב אותו לקובץ עם הרשאות 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 פירושו שרק המשתמש שלך יכול לקרוא את הקובץ. ודא שהמפתח הגיע לסביבה באמצעות printenv GEMINI_API_KEY; אם הפקודה לא מדפיסה דבר, ה-CLI יחזור לתהליך הדפדפן וייכשל. ה-CLI קורא גם קובץ .env ב-~/.gemini/ אם אתה מעדיף את המבנה הזה — אותה כלל, לכן השתמש ב-chmod 600 ~/.gemini/.env.

הדרך השנייה שומרת על ההתחברות באמצעות חשבון Google אישי (ועל המסלול החינמי שלו) על ידי יצירת מנהרה (tunneling) של ה-OAuth callback חזרה ללפטופ שלך. המכשול הוא ששרת ה-loopback של ה-CLI מקשר (binds) פורט אקראי בכל ריצה, לכן אין פורט קבוע להעביר אלא אם תקבע אותו מראש באמצעות משתנה הסביבה OAUTH_CALLBACK_PORT, ולאחר מכן תעביר בדיוק את הפורט הזה:

# 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; פתח אותה בדפדפן בלפטופ, אשר, וכאשר Google תבצע הפניה ל-http://localhost:8085/..., הפורט של ה-SSH יעביר את הבקשה לשרת ה-loopback ב-VPS וההתחברות תסתיים. אם לא תקבע את הפורט, הוא יקבל פורט אקראי חדש בכל ריצה, מה ששום ssh -L שיוגדר מראש לא יוכל לתפוס. זה עובד, אך זה דורש ממך לשבת מול דפדפן, ולכן זה לא מתאים לסקריפטים. עבור כל דבר שאתה משאיר פועל, השתמש ב-API key.

עבור Vertex AI או פרויקט Google Cloud במקום AI Studio, הגדר את GOOGLE_API_KEY יחד עם GOOGLE_GENAI_USE_VERTEXAI=true, או את GOOGLE_CLOUD_PROJECT עבור רישיון Code Assist — אותה משמעת של משתני סביבה, אותו קובץ mode-600.

הרץ את הפקודה בתוך tmux כדי שניתוק של SSH לא יסתיים את התהליך

תהליך gemini המופעל ישירות מתוך ה-SSH shell שלך הוא תהליך בן (child process) של ה-shell הזה. אם החיבור יתנתק — עקב סגירת המחשב, ניתוק Wi-Fi או פקיעת זמן המתנה (idle timeout) — ה-sshd יסגור את ה-pseudo-terminal, ה-shell יקבל SIGHUP, וה-CLI יתנתק בעצמו. משימה שנמצאת באמצע עריכת קבצים במשך עשר דקות תמות יחד איתו, ולאחר התחברות מחדש לא יהיה תהליך לשחזור.

tmux פותרת זאת על ידי ניהול ה-shell במקום שsshd מנהל אותו. זהו אותו דפוס כמו running an AI coding agent on a remote VPS inside 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 מתחברת ל-session בשם gemini אם הוא קיים, ויוצרת אחד חדש אם הוא לא קיים. לכן, זו הפקודה היחידה שיש להריץ מיד לאחר כל התחברות. ה-shell שבתוך ה-tmux שייך ל-detached tmux server ולא ל-SSH session שלך, ולכן ניתוק החיבור משאיר את ה-CLI פעיל. התחבר מחדש, בצע attach, ותחזור בדיוק לאותו היסטוריית פקודות (scrollback).

עבור הרצות מבוססות סקריפטים ללא אינטראקציה, ל-Gemini CLI יש מצב headless: gemini -p "summarise the failing tests in this repo" מדפיס תשובה ויוצא, ו---output-format json מספק פלט בפורמט machine-readable כדי להעביר אותו (pipe) למקום אחר. מצב headless עם API key הוא בדיוק מה שנדרש בתוך tmux session המריץ משימת batch ארוכה, או כזה המופעל מתוך cron — עם הערה אחת: משימת cron אינה טוענת אף אחד מקבצי ה-login שלך. לכן, יש לספק לשורת ה-crontab את ה-GEMINI_API_KEY משלה (או לגרום לפקודה לטעון את ~/.gemini_env), אחרת ה-CLI ינסה לעבור לתהליך הדפדפן ויכשל.

Sandboxing ורשאויות במערכת המריצה גם Production

סוכן עם גישת shell הוא shell. Gemini CLI יכול להריץ פקודات, ובמצב ברירת מחדל הוא מבקש אישור לפני כל פקודה מסוכנת — אך משתמשים נוטים להשתמש ב---yolo (אישור אוטומטי לכל קריאת כלי), ואז הוא יכול למחוק קבצים, לבצע push ל-git, או לפנות לשירותים פנימיים עם כל ההרשאות של המשתמש המריץ. במערכת המריצה גם production, זהו blast radius אמיתי ולא היפותטי.

שלוש בקרית, לפי רמת ההגנה שהן מספקות:

• הרץ את הסוכן תחת משתמש ייעודי ללא הרשאות גבוהות. לא root, ולא חבר בקבוצת sudo. צור משתמש agent עם home directory משלו, התקן את Node ואת ה-CLI שם, כך שפקודה שגויה תישאר מוגבלת לאותו חשבון בלבד. זוהי ההחלטה בעלת הערך הגבוה ביותר.
• אל תשמור הרשאות production על המכונה. ללא ~/.aws/credentials של production, ללא .env שהועתקו מ-production, וללא סיסמת מסד נתונים עם הרשאת כתיבה לכל דבר קריטי. הקצה לו הרשאות staging או הרשאות לקריאה בלבד (read-only).
• השתמש ב-sandbox המובנה. כאשר Docker או Podman מותקנים, gemini --sandbox (או GEMINI_SANDBOX=docker) מריץ את קריאות הכלי של הסוכן בתוך container מבודד ממערכת הקבצים והרשת של המארח (host). זה אינו תחליף למשתמש ללא הרשאות, אך זוהי שכבת הגנה שנייה חזקה כאשר אותו VPS מבצע גם עבודה אמיתית.

אם אתה מריץ את Gemini CLI לצד כלי self-hosted אחרים — למשל שרת MCP החושף כלים לסוכן באותו VPS — התייחס לכל יכולת מוספת כשטח תקיפה נוסף שהסוכן יכול להגיע אליו, והגבל את ה-tokens שהוא מקבל למשימה אחת בלבד.

מכסה (Quota), עלות ונתיב האימות שנבחר

נתיב האימות קובע כיצד תחושב החיוב. חשבון Google אישי (נתיב ה-OAuth) משתמש בשכבה החינמית של Gemini Code Assist, עם מגבלות אמיתיות לדקה וליום; חריגה מהן תגרום לשגיאת rate-limit עד לסיום חלון הזמן. מפתח API מ-AI Studio יכול להיות בשכבה חינמית או בתשלום, תלוי בפרויקט — מפתח בתשלום מעלה את המגבלות ומחייב לפי token. אימות דרך Vertex או פרויקט Cloud מתבצע באמצעות Google Cloud.

שתי הערות מעשיות. סוכן (agent) הפועל בלולאה ללא השגחה עלול לצרוך את המכסה במהירות, לכן יש לעקוב אחריו בפעמים הראשונות לפני שמגדירים אותו כ-cron job. ושם אם הסיבה לשימוש במודל בצד השרת היא פרטיות או inference ללא מדידה (unmetered), ולא מודלים מארחים של Google, מדובר בכלי שונה — self-hosting an open LLM with Ollama on a VPS שומר את המשקלים (weights) ואת ה-prompts על השרת הפרטי שלך, במחיר של הרצת מודל קטן בהרבה מ-Gemini.

Keeping it updated

Gemini CLI מתעדכן לעיתים תכופות. מכיוון שהתקנת אותו ב-prefix בבעלות משתמש, אין צורך ב-sudo לצורך עדכונים:

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

קיימים ערוצי גרסאות: @latest הוא היציב, @preview הוא גרסת Preview שבועית, ו-@nightly הוא גרסת bleeding edge — מומלץ להשתמש ב-@latest בכל מערכת שאתה מסתמך עליה. ב-nvm, חבילות גלובליות נמצאות תחת גרסת ה-Node הפעילה, לכן לאחר nvm use כדי להחליף את גרסת ה-Node, ייתכן שיהיה צורך להתקין מחדש את ה-CLI. מומלץ לקרוא את ה-release notes במקום לרדוף אחרי כל patch.

Failure modes, with the exact strings

npm WARN EBADENGINE Unsupported engine ... required: { node: '>=20' }, ואז קריסת ה-CLI בזמן ריצה. גרסת ה-Node ישנה מדי — ב-distro מותקנת גרסה 18.19.1, שהיא גם מעבר לתאריך ה-end-of-life. התקן Node 20+ מ-NodeSource או מ-nvm, וודא באמצעות node --version. אם מותקנות מספר גרסאות Node, וודא ש-which node מצביע על הגרסה החדשה ולא על /usr/bin/node.

npm error code EACCES / permission denied, mkdir '/usr/lib/node_modules/...'. התקנה גלובלית לתוך prefix בבעלות root. אל תשתמש ב-sudo — הגדר את npm config set prefix ~/.npm-global, הגדר את ~/.npm-global/bin ב-PATH, והתקן מחדש כמשתמש הרגיל שלך. אם sudo npm קודם השאיר קבצי cache בבעלות root (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 callback שלו מצביע על השרת ולא על הלפטופ שלך. השתמש בנתיב ה-API-key (GEMINI_API_KEY), או קבע את OAUTH_CALLBACK_PORT, בצע forward דרך SSH באמצעות ssh -L, ופתח את ה-URL באופן מקומי.

התהליך נעלם כאשר ה-SSH התנתק. הרצת את gemini ישירות מתוך ה-SSH shell, ולכן הוא היה תהליך בן (child) של ה-shell ונסגר יחד עם ה-pty עם ניתוק החיבור. אין מה לשחזר. התחל כל session עם tmux new -A -s gemini והרץ את ה-CLI בתוכו.

האימות נכשל למרות שהמפתח הוגדר — ה-CLI חוזר לתפריט בחירת האימות, או ש-request מחזיר API key not valid עם HTTP 400. המפתח אינו נמצא ב-environment שה-CLI רואה. ודא זאת באמצעות printenv GEMINI_API_KEY; אם הוא ריק, ה-~/.gemini_env שלך לא נטען (sourced) — בדוק שהשורה קיימת ב-~/.bashrc, ש-interactive shells (כולל tmux) קוראים להם, אך cron ו-shells לא-אינטראקטיביים אחרים לא. רווח או גרש מיותר בתוך ערך המפתח יגרמו גם הם ל-API key not valid.

429 / RESOURCE_EXHAUSTED / הודעת rate-limit. הגעת למכסה (quota) של רמת האימות שבה אתה משתמש. המתן לאיפוס ה-window, האט את מהירות ה-agent, או עבור ל-API key בתשלום. agent שנתקע בלולאת retry ימשיך להיתקל בשגיאה זו — עצור אותו ובדוק מה הוא מבצע.

FAQ

איך מבצעים אימות (authentication) ל-Gemini CLI בשרת ללא ממשק גרפי (headless)?

השתמש במפתח API במקום בהתחברות דרך הדפדפן. צור מפתח ב-Google AI Studio, שמור אותו בקובץ mode-600 שסביבת העבודה שלך טוענת (export GEMINI_API_KEY=...), וה-CLI ידלג לחלוטין על תהליך ה-OAuth בדפדפן. אם ברצונך להשתמש בשירות החינמי של החשבון האישי, קבע את ה-loopback port באמצעות OAUTH_CALLBACK_PORT=8085, בצע forward ל-laptop שלך באמצעות ssh -L 8085:localhost:8085 user@server, ופתח את ה-URL שהודפס מקומית — אך שיטה זו דורשת נוכחות בדפדפן, ולכן היא אינה מתאימה לשימוש ב-scripts.

מדוע ההתקנה הגלובלית של npm דורשת sudo, ואיך נמנע מכך?

מכיוון שה-prefix הגלובלי الافتراضي של npm הוא /usr/lib/node_modules, ואין למשתמש הרגיל הרשאת כתיבה אליו, לכן פקודת npm install -g רגילה תיכשל עם EACCES. הפתרון השגוי הוא sudo npm -g, שמשאיר קבצים בבעלות root וגורם לכשל בהתקנות עתידיות. הפתרון הנכון הוא להגדיר את ה-prefix לתיקיית הבית שלך (npm config set prefix ~/.npm-global) ולהוסיף את ה-bin שלה ל-PATH, או להשתמש ב-nvm, המתקין חבילות גלובליות תחת תיקיית הבית באופן אוטומטי.

איך משאירים את Gemini CLI רץ גם לאחר ניתוק החיבור?

הרץ אותו בתוך tmux. תהליך שהופעל מתוך shell של SSH ייעצר ברגע שהחיבור יתנתק, מכיוון שהוא תהליך בן (child process) לאותו shell; tmux מריץ את ה-shell תחת server מנותק (detached) ששורד את הניתוק. השתמש ב-tmux new -A -s gemini, הרץ את gemini בתוכו, בצע detach באמצעות Ctrl-b d, וחזור אליו מאוחר יותר באמצעות tmux attach -t gemini.

האם בטוח להריץ את Gemini CLI על שרת ייצור (production)?

רק בזהירות, מכיוון שסוכן (agent) עם גישה ל-shell יכול לבצע כל פעולה שהמשתמש שמריץ אותו יכול לבצע. הרץ אותו תחת משתמש ייעודי ללא הרשאות sudo, אל תשמור פרטי גישה של סביבת הייצור על המכונה, הימנע מאישור אוטומטי של --yolo, והשתמש ב---sandbox (Docker או Podman) כדי לבודד את קריאות הכלי מהמארח (host). סוג החשבון שמריץ את התהליך חשוב יותר מכל flag שתוכל להגדיר.

האם יש צורך לפתוח פורטים ב-firewall עבור Gemini CLI?

לא. זהו client שמבצע קריאות HTTPS יוצאות (outbound) ל-APIs של Google, ולכן הוא זקוק לפורט 443 יוצא בלבד, ללא צורך בפורטים נכנסים (inbound). אם משתמשים ב-OAuth tunnel, פורט ה-callback המקובע (למשל 8085) נמצא ב-localhost ונגיש דרך ה-SSH forward שלך, ולא דרך פורט נכנס פתוח. יש להשאיר את הפורטים הנכנסים חסומים.