הרצת Gemini CLI על שרת VPS ללא ממשק גרפי

מה אתם בונים

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

Gemini CLI הוא תוכנת Node בקוד פתוח (Apache-2.0) (@google/gemini-cli) המתקשרת עם מודלי ה-Gemini של Google. התוכנה מסוגלת לקרוא ולכתוב קבצים, להריץ פקודות shell ולהפעיל כלים בתיקיית העבודה. על גבי VPS, מדובר בסוכן קטן וזמין תמיד שניתן להשאיר בעבודה; זו הסיבה שהחשבון שבו הוא רץ וההרשאות המאוחסנות על השרת חשובים יותר מכל הגדרה בודדת במדריך זה.

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

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

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

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

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) שאינה נתמכת, מה שיוביל להתנהגות שגויה או לקריסה ברגע שהתוכנה תנסה לגשת ל־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. אל תשתמשו בה. הגדרת 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, אלא הפניית ה-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 בעוד שני סעיפים, מפעיל shell שאינו 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.

בעיית האימות בשרת ללא ממשק גרפי (Headless) ודרכי פתרון

הפעלת gemini באופן אינטראקטיבי בפעם הראשונה תציע לכם להתחבר באמצעות חשבון ה-Google שלכם. בסביבת שולחן עבודה, פעולה זו פותחת לשונית בדפדפן. בשרת VPS ללא ממשק גרפי אין דפדפן, ולכן התהליך או מדפיס כתובת URL של 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. גם אם תפתחו את ה-URL הזה במחשב הנייד שלכם ותאשרו את החיבור, Google תבצע הפניה (redirect) ל-http://localhost:PORT, כלומר ל-localhost על השרת עצמו, פורט שאף רכיב במחשב הנייד שלכם אינו יכול להגיע אליו. תהליך ההתחברות לעולם לא יושלם.

קיימות שתי דרכים הגונות לעקוף זאת.

הראשונה היא שימוש ב-API key, וזוהי ברירת המחדל הנכונה עבור שרת. צרו מפתח ב-Google AI Studio (aistudio.google.com) והזינו אותו לכלי ה-CLI כמשתנה סביבה; הכלי יקרא את GEMINI_API_KEY וידלג על תהליך הדפדפן לחלוטין. כעת, לגבי החלק של "שמירה מחוץ להיסטוריה ומחוץ לקבצים הנגישים לכולם": אל תקלידו export GEMINI_API_KEY=AIza... בשורת הפקודה, שכן הדבר יירשם ב-~/.bash_history בטקסט גלוי, ואל תשימו את המפתח בקובץ שמשתמשים אחרים יכולים לקרוא. כתבו אותו לקובץ עם הרשאות 600 שה-shell טוען בעת ההפעלה:

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 יחזור לתהליך הדפדפן וייכשל. הכלי קורא גם קובץ .env בתוך ~/.gemini/ אם אתם מעדיפים מבנה זה, עם אותם כללי אבטחה, לכן השתמשו ב-chmod 600 ~/.gemini/.env.

הדרך השנייה שומרת על ההתחברות לחשבון ה-Google האישי (ועל שכבת השימוש החינמית שלו) על ידי יצירת מנהרה (tunnel) ל-callback של ה-OAuth בחזרה למחשב הנייד שלכם. המלכודת היא ששרת ה-loopback של ה-CLI מאזין לפורט אקראי בכל הרצה, כך שאין פורט קבוע להעברה (forward) אלא אם כן תקבעו אותו מראש באמצעות משתנה הסביבה 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 אינו יכול לפתוח דפדפן, לכן הוא מדפיס את ה-URL לאימות; פתחו אותו בדפדפן במחשב הנייד, אשרו, וכאשר 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, תוך הקפדה על אותה משמעת של משתני סביבה וקובץ בהרשאות 600.

הריצו זאת בתוך tmux כדי שניתוק של סשן SSH לא יפסיק את התהליך

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

tmux פותר זאת על ידי כך שהוא הופך לבעלים של ה-shell במקום ש-sshd יהיה הבעלים. זהו אותו דפוס פעולה כמו ב-הרצת סוכן קידוד מבוסס AI על VPS מרוחק בתוך 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 אם הוא קיים, ויוצרת אותו אם לא; לכן זו הפקודה היחידה שיש להריץ מיד לאחר כל התחברות. ה-shell שבפנים שייך לשרת ה-tmux המנותק, לא לסשן ה-SSH שלכם, כך שניתוק החיבור משאיר את ה-CLI פעיל. התחברו מחדש, בצעו attach, ותחזרו לאותו מצב גלילה. אם אתם מריצים כמה סשנים של סוכנים על שרת אחד, אחד לכל סשן tmux, אין להם דרך לתקשר זה עם זה כאן, בניגוד ל-Claude Code, שבו סשן אחד יכול להעביר טקסט לאחר על אותו VPS, לכן שמרו על כל משימת Gemini עצמאית או תאמו ביניהן באמצעות קבצים על הדיסק.

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

ארגז חול והרשאות בשרת המריץ סביבת ייצור

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

שלושה אמצעי בקרה, לפי סדר חשיבותם:

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

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

מכסות, עלות ומסלול האימות שבחרת

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

שתי הערות מעשיות: סוכן אוטונומי בלולאה עלול לצרוך את המכסה במהירות, לכן יש לנטר אותו בפעמים הראשונות לפני שסומכים עליו בהרצה ב-cron job. אם הסיבה לשימוש במודל צד-שרת היא פרטיות או הסקה (inference) ללא הגבלת כמות, ולא שימוש במודלים המנוהלים של Google, מדובר בכלי אחר; אירוח עצמי של LLM פתוח באמצעות Ollama על גבי VPS שומר את המשקולות (weights) ואת ה-prompts על השרת שלך, במחיר של הרצת מודל קטן משמעותית מ-Gemini.

שמירה על עדכניות

הכלי Gemini CLI משחרר גרסאות לעיתים קרובות. מכיוון שהתקנת אותו בנתיב שבבעלות המשתמש, עדכונים אינם דורשים הרשאות sudo:

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

קיימים ערוצי הפצה: @latest הוא הערוץ היציב, @preview הוא גרסת ה-preview השבועית, ו-@nightly הוא ערוץ הפיתוח המתקדם ביותר; מומלץ לקבע (pin) ל-@latest בכל שירות שאתה מסתמך עליו. ב-nvm, חבילות גלובליות נמצאות תחת גרסת ה-Node הפעילה, לכן לאחר nvm use כדי להחליף גרסת Node, ייתכן שתצטרך להתקין מחדש את ה-CLI. קרא את הערות השחרור במקום לרדוף אחרי כל תיקון קטן.

מצבי כשל, עם מחרוזות מדויקות

npm WARN EBADENGINE Unsupported engine ... required: { node: '>=20' }, ולאחר מכן קריסה של ה-CLI בזמן הריצה. גרסת ה-Node ישנה מדי; ההפצה משתמשת ב-18.19.1, שכבר הגיעה לסוף חייה (EOL). התקינו Node 20 ומעלה מ-NodeSource או מ-nvm, אשרו את הגרסה עם node --version, ואם מותקנות אצלכם כמה גרסאות Node, ודאו ש-which node מצביע על הגרסה החדשה ולא על /usr/bin/node.

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

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

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

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

FAQ

כיצד מאמתים את Gemini CLI בשרת ללא ממשק גרפי (headless)?

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

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

מכיוון שקידומת ה-global המוגדרת כברירת מחדל ב-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. תהליך שמתחיל מתוך ה-SSH shell שלכם מסתיים עם ניתוק החיבור, כיוון שהוא תהליך בן של אותו shell; ה-tmux מריץ את ה-shell תחת שרת מנותק ששורד את הניתוק. השתמשו ב-tmux new -A -s gemini, הריצו את gemini בפנים, בצעו ניתוק (detach) עם Ctrl-b d, וחזרו לחיבור (reattach) מאוחר יותר עם tmux attach -t gemini.

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

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

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

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