تشغيل Gemini CLI على خادم VPS بلا واجهة

ما الذي تبنيه

أداة Gemini CLI تعمل باستمرار على خادم تملكه أنت، ويمكن الوصول إليه عبر SSH، وتشغّل مهام وكيل (agent) طويلة تواصل العمل بعد أن تغلق حاسوبك المحمول. التثبيت نفسه ثلاثة أوامر فقط. أما ما يتطلب عملًا فهو كل ما يفترض وجود بيئة سطح مكتب: أداة Google تريد فتح متصفح لتسجّل دخولك، وخادمك لا يملك واحدًا. لذلك فمعظم هذا الدليل يغطي المسار بلا واجهة رسومية (headless): Node حديث لن تمنحك إياه التوزيعة، وتثبيت npm عام لا يحتاج إلى root، ومصادقة بلا متصفح عبر مفتاح API تبقيه بعيدًا عن سجل أوامر الصدفة (shell) لديك، وtmux حتى لا تأخذ جلسة SSH منقطعة معها مهمة قيد التشغيل.

Gemini CLI برنامج مفتوح المصدر (Apache-2.0) مكتوب بـ Node (‏@google/gemini-cli‏) يتواصل مع نماذج Gemini من Google، وقادر على قراءة الملفات وكتابتها، وتشغيل أوامر الصدفة، وتوجيه أدوات داخل مجلد العمل. على خادم VPS هو وكيل صغير متاح باستمرار يمكنك تركه يعمل — ولهذا فإن الحساب الذي يعمل تحته، وبيانات الاعتماد الموجودة على الجهاز، أهم من أي إعداد منفرد هنا.

المتطلبات المسبقة والعقبات الصريحة

• خادم VPS جديد بنظام Ubuntu 24.04 من نوع KVM مع صلاحيات root أو sudo. أي باقة KVM تصلح؛ فالأداة نفسها خفيفة، بضع مئات من الميغابايتات من ذاكرة RAM عند السكون.
• Node.js بإصدار 20 أو أحدث. هذا هو الحد الأدنى الصارم الوحيد للإصدار، وحزمة التوزيعة أقل منه — انظر القسم التالي.
• HTTPS صادر (المنفذ 443) نحو واجهات برمجة تطبيقات (APIs) Google. لا حاجة إلى أي منافذ واردة؛ فهذا عميل (client) لا خادم، ولذلك لا تفتح أي ثغرة في جدار الحماية من أجله.
• وسيلة للمصادقة لا تحتاج إلى متصفح على الخادم: إما مفتاح Gemini API من Google AI Studio، أو نفق SSH يعيدك إلى متصفح على جهازك أنت. مسار مفتاح API هو الأنسب للسكربتات والتشغيل دون إشراف.
• Docker أو Podman، فقط إن أردت عزل --sandbox. اختياري، ونتناوله قرب النهاية.

العقبة التي يقع فيها الجميع: تدفق تسجيل الدخول الودّي عند أول تشغيل لأمر gemini مصمَّم لسطح مكتب. يحاول فتح متصفح، وعلى جهاز بلا واجهة إما يفشل أو يمنحك رابطًا لا يعمل. قرّر مسار المصادقة قبل أن تبدأ.

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 }

تجاوز ذلك التحذير، وتعمل الأداة على بيئة تشغيل غير مدعومة، حيث تسيء التصرف أو تنهار في اللحظة التي تصل فيها إلى واجهة برمجية من Node 20+ تتوقع وجودها. كما بلغ Node 18 نهاية دعمه (end-of-life) في أبريل 2025، فهو طريق مسدود على أي حال. ثبّت إصدار LTS حديثًا قبل أن تثبّت الأداة. المساران النظيفان هما 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 في الرابط هو السطر الذي تحدّثه حين يصدر 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 في ذلك الرابط هو الأحدث وقت كتابة هذا الدليل؛ راجع ملف README الخاص بـ nvm لمعرفة أحدث إصدار، واستبدل الرقم قبل أن تنفّذ الأمر. لدى nvm ميزة حقيقية لهذه المهمة: فهو يثبّت Node وحزمه العامة تحت ~/.nvm، وبذلك لا تقع مشكلة أذونات التثبيت العام الموصوفة في القسم التالي إطلاقًا. إن سلكت مسار nvm، يمكنك تخطي خطوة بادئة (prefix) npm كليًا.

ثبّت الأداة بلا sudo npm -g

الأمر المُغري هو sudo npm install -g @google/gemini-cli. لا تفعل ذلك. فبادئة (prefix) عامة مملوكة لـ root تنتج أخطاء أذونات في كل تثبيت لاحق، وتترك في ذاكرة npm المخبأة (cache) ملفات مملوكة لـ root تسبب لك مشكلة بعد أشهر. نفّذ أمر 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 — بل توجيه بادئة 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 — الذي ستشغّل الأداة داخله بعد قسمين من هنا — يبدأ صدفة (shell) لا تتطلب تسجيل دخول تقرأ ~/.bashrc وتتجاوز ~/.profile، فسطر PATH في الملف الخاطئ يترك gemini غير مرئي في المكان الذي تحتاجه فيه بالضبط. الاختبار كله هو أن يطبع gemini --version رقم إصدار. إن حصلت بدلًا من ذلك على gemini: command not found، فتصدير PATH لديك لم يُطبَّق — انظر أنماط الفشل. مع nvm، تجاوز أسطر البادئة كليًا: فهو يثبّت الحزم العامة أصلًا تحت مجلدك الشخصي.

إن كنت قد نفّذت sudo npm في وقت سابق وترى الآن Your cache folder contains root-owned files، أصلح ذلك مرة واحدة بالأمر sudo chown -R $(id -u):$(id -g) ~/.npm.

مشكلة المصادقة بلا واجهة، وكيفية تجاوزها

شغّل gemini تفاعليًا للمرة الأولى، وسيعرض عليك تسجيل الدخول بحساب Google الخاص بك. على سطح مكتب يفتح ذلك تبويب متصفح. أما على خادم VPS بلا واجهة فلا يوجد متصفح، فإما أن يطبع التدفق رابط 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، وهي الخيار الافتراضي الصحيح لخادم. أنشئ مفتاحًا في Google AI Studio (أي aistudio.google.com) وسلّمه إلى الأداة كمتغير بيئة؛ فهي تقرأ 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؛ فإن لم يطبع شيئًا، تعود الأداة إلى تدفق المتصفح وتفشل. كما تقرأ الأداة ملف .env في ~/.gemini/ إن فضّلت هذا الترتيب — القاعدة نفسها تنطبق، فنفّذ chmod 600 ~/.gemini/.env.

الطريقة الثانية تُبقي تسجيل الدخول بالحساب الشخصي على Google (وفئته المجانية) عبر تمرير استدعاء OAuth الرجعي (callback) في نفق يعيده إلى حاسوبك المحمول. المشكلة أن خادم الأداة الرجعي (loopback) يربط منفذًا عشوائيًا في كل تشغيل، فلا يوجد شيء ثابت لتمريره ما لم تثبّته أولًا عبر متغير البيئة 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

لا تستطيع الأداة فتح متصفح، فتطبع رابط المصادقة؛ افتحه في متصفح حاسوبك المحمول، وافق عليه، وحين تعيد Google التوجيه إلى http://localhost:8085/... يحمله تمرير SSH إلى الخادم الرجعي على VPS ويكتمل تسجيل الدخول. اترك المنفذ بلا تثبيت وسيحطّ على منفذ عشوائي جديد في كل تشغيل، لا يستطيع أي ssh -L أُعِدَّ مسبقًا التقاطه. الطريقة تعمل، لكنها تتطلب وجودك أمام متصفح، فلا تصلح للسكربتات. لأي شيء تتركه يعمل، استخدم مفتاح API.

بالنسبة لـ 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 لديك هي عملية تابعة (child) لتلك الصدفة. إن انقطع الاتصال — أُغلق الحاسوب المحمول، انقطعت شبكة Wi-Fi، أو انتهت مهلة الخمول — فكّك sshd الطرفية الوهمية (pseudo-terminal)، وتلقّت الصدفة إشارة SIGHUP، فقطعت الاتصال بدورها عن الأداة. مهمة في الدقيقة العاشرة من تعديل الملفات تموت معها، وعند إعادة الاتصال لا توجد عملية لاستعادتها.

يُصلح tmux ذلك بامتلاك الصدفة بدلًا من sshd. هذا هو النمط نفسه المتبع في تشغيل وكيل برمجة بالذكاء الاصطناعي على خادم 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 إن كانت موجودة، وينشئها إن لم تكن، فهو الأمر الوحيد الذي تنفّذه فور كل تسجيل دخول. الصدفة بالداخل مملوكة لخادم tmux المنفصل، لا لجلسة SSH لديك، فانقطاع الاتصال يترك الأداة تعمل. أعد الاتصال، اتصل بالجلسة، وستجد نفسك في سجلّ التمرير (scrollback) نفسه.

أما للتشغيل غير التفاعلي عبر السكربتات، فلدى Gemini CLI وضع بلا واجهة (headless): الأمر gemini -p "summarise the failing tests in this repo" يطبع إجابة وينتهي، والخيار --output-format json يوفّر مخرجات قابلة لقراءة الآلة لتمريرها إلى مكان آخر. وضع بلا واجهة مع مفتاح API هو بالضبط ما تريده داخل جلسة tmux تشغّل مهمة دفعية طويلة، أو مُطلَقة من إدخال cron — مع تحذير واحد: مهمة cron لا تحمّل أيًا من ملفات تسجيل الدخول لديك، فامنح سطر crontab متغير GEMINI_API_KEY الخاص به (أو اجعل الأمر يحمّل ~/.gemini_env)، وإلا عادت الأداة إلى تدفق المتصفح وفشلت.

العزل والصلاحيات على خادم يشغّل الإنتاج أيضًا

وكيل يملك وصولًا إلى الصدفة هو صدفة. يستطيع Gemini CLI تشغيل أوامر، وهو يطلب الإذن افتراضيًا قبل كل أمر محفوف بالمخاطر — لكن الناس يلجؤون إلى --yolo (الموافقة التلقائية على كل استدعاء أداة)، وعندها يستطيع حذف الملفات، أو الدفع (push) إلى git، أو مخاطبة خدمات داخلية بكامل صلاحيات المستخدم الذي يعمل تحته. على جهاز يشغّل الإنتاج أيضًا، هذا نطاق ضرر حقيقي، لا افتراض نظري.

ثلاثة ضوابط، مرتبة حسب مقدار ما تمنحك إياه:

• شغّله بمستخدم مخصص غير مميّز الصلاحيات. ليس root، وليس عضوًا في sudo. أنشئ مستخدم agent بمجلده الشخصي الخاص، وثبّت Node والأداة هناك، وبذلك تبقى أي تعليمة أُسيء فهمها محصورة في ذلك الحساب. هذا هو القرار الأعلى قيمة على الإطلاق.
• أبقِ بيانات اعتماد الإنتاج بعيدة عن الجهاز. لا ~/.aws/credentials خاص بالإنتاج، ولا .env منسوخ من الإنتاج، ولا كلمة مرور قاعدة بيانات بصلاحية كتابة على أي شيء مهم. امنحه بيانات اعتماد بيئة تجريبية (staging) أو للقراءة فقط.
• استخدم البيئة المعزولة (sandbox) المدمجة. مع تثبيت Docker أو Podman، ينفّذ gemini --sandbox (أو GEMINI_SANDBOX=docker) استدعاءات أدوات الوكيل داخل حاوية معزولة عن نظام ملفات المضيف وشبكته. هذا ليس بديلًا عن المستخدم غير المميَّز الصلاحيات، لكنه طبقة ثانية قوية حين يقوم الخادم نفسه بعمل حقيقي.

إن كنت تشغّل Gemini CLI جنبًا إلى جنب مع أدوات أخرى مستضافة ذاتيًا — خادم MCP يعرض أدوات على الوكيل على الخادم نفسه مثلًا — فعامل كل قدرة مضافة على أنها سطح إضافي يستطيع الوكيل بلوغه، واحصر الرموز (tokens) الممنوحة له في مهمة واحدة بعينها.

الحصة والتكلفة، ومسار المصادقة الذي اخترته

مسار المصادقة هو ما يحدد كيفية فوترتك. حساب Google الشخصي (مسار OAuth) يستخدم فئة Gemini Code Assist المجانية، بحدود حقيقية لكل دقيقة ولكل يوم؛ تجاوزها يجعل الطلبات ترجع بخطأ حد المعدل (rate-limit) حتى تُعاد ضبط النافذة. مفتاح API من AI Studio قد يكون ضمن الفئة المجانية أو مدفوعًا حسب المشروع — والمفتاح المدفوع يرفع الحدود ويفرض رسومًا لكل رمز نصي (token). أما مصادقة Vertex ومشروع Cloud فيُفوتَران عبر Google Cloud.

ملاحظتان عمليتان. وكيل يعمل دون إشراف في حلقة تكرار قد يستهلك الحصة بسرعة، فراقبه في المرات الأولى قبل أن تثق به مع مهمة cron. وإن كان سبب رغبتك في نموذج على جانب الخادم هو الخصوصية أو استدلال (inference) غير محسوب على أساس الاستخدام بدلًا من نماذج Google المستضافة، فتلك أداة مختلفة — استضافة LLM مفتوح المصدر ذاتيًا باستخدام Ollama على خادم VPS تُبقي الأوزان (weights) والمُوجِّهات (prompts) على جهازك أنت، مقابل تشغيل نموذج أصغر بكثير من Gemini.

الحفاظ عليه محدَّثًا

تصدر تحديثات Gemini CLI بكثرة. ولأنك ثبّتها في بادئة مملوكة للمستخدم، لا تحتاج التحديثات إلى sudo أبدًا:

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

توجد قنوات إصدار: @latest مستقر، و@preview هو المعاينة الأسبوعية، و@nightly هو أحدث ما هو قيد التطوير — ثبّت @latest على كل ما تعتمد عليه. مع nvm، تقع الحزم العامة ضمن إصدار Node النشط، فبعد nvm use لتبديل Node قد تحتاج إلى إعادة تثبيت الأداة. اقرأ ملاحظات الإصدار بدلًا من ملاحقة كل تحديث طفيف.

أنماط الفشل، مع النصوص الحرفية

‏npm WARN EBADENGINE Unsupported engine ... required: { node: '>=20' }، ثم انهيار الأداة عند التشغيل. Node قديم جدًا — نسخة التوزيعة 18.19.1، التي بلغت أيضًا نهاية دعمها. ثبّت 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 يريد متصفحًا لا يملكه الخادم، واستدعاؤه الرجعي عبر localhost يشير إلى الخادم، لا إلى حاسوبك المحمول. استخدم مسار مفتاح API (‏GEMINI_API_KEY‏)، أو ثبّت OAUTH_CALLBACK_PORT، ومرّره عبر SSH بالأمر ssh -L، وافتح الرابط محليًا.

اختفت العملية حين انقطع SSH. شغّلت gemini مباشرة من صدفة SSH، فكانت عملية تابعة لتلك الصدفة وماتت مع الطرفية الوهمية (pty) عند الانقطاع. لا شيء لاستعادته. ابدأ كل جلسة بالأمر tmux new -A -s gemini وشغّل الأداة بداخله.

المصادقة ما زالت تفشل رغم ضبط المفتاح — تعود الأداة إلى منتقي المصادقة، أو تعود الاستجابة برسالة API key not valid ورمز الحالة HTTP 400. المفتاح غير موجود في البيئة التي تراها الأداة. تأكد بالأمر printenv GEMINI_API_KEY؛ إن كان فارغًا، فملف ~/.gemini_env لديك لم يُحمَّل قط — تحقق من أن السطر موجود في ~/.bashrc، الذي تقرؤه الصدفات التفاعلية (بما فيها tmux) لكن لا يقرؤه cron ولا غيره من الصدفات غير التفاعلية. مسافة أو علامة اقتباس زائدة داخل قيمة المفتاح تنتج أيضًا API key not valid.

‏429 / RESOURCE_EXHAUSTED / رسالة حد معدل. بلغت حصة أيًا كانت الفئة التي تستخدمها مصادقتك. انتظر إعادة ضبط النافذة، أو أبطئ الوكيل، أو انتقل إلى مفتاح API مدفوع. وكيل عالق في حلقة إعادة محاولة يواصل الاصطدام بهذا — أوقفه وتحقق مما يفعله.

FAQ

كيف أُصادق Gemini CLI على خادم بلا واجهة؟

استخدم مفتاح API، لا تسجيل الدخول بالمتصفح. أنشئ مفتاحًا في Google AI Studio، وضعه في ملف بصلاحيات 600 تُحمِّله الصدفة لديك (‏export GEMINI_API_KEY=...‏)، وتتجاوز الأداة تدفق OAuth عبر المتصفح كليًا. إن أردت تحديدًا الفئة المجانية للحساب الشخصي، ثبّت المنفذ الرجعي بـ OAUTH_CALLBACK_PORT=8085، ومرّره إلى حاسوبك المحمول بالأمر ssh -L 8085:localhost:8085 user@server، وافتح الرابط المطبوع محليًا — لكن هذا يتطلب وجودك أمام متصفح، فلا يصلح للسكربتات.

لماذا يطلب التثبيت العام لـ npm صلاحيات sudo، وكيف أتجنب ذلك؟

لأن البادئة العامة الافتراضية لـ npm هي /usr/lib/node_modules، ومستخدمك لا يستطيع الكتابة فيها، فيفشل npm install -g العادي بخطأ EACCES. الحل الخاطئ هو sudo npm -g، الذي يترك ملفات مملوكة لـ root تعطّل التثبيتات اللاحقة. الحل الصحيح هو توجيه البادئة نحو مجلدك الشخصي (‏npm config set prefix ~/.npm-global‏) وإضافة مجلد bin الخاص بها إلى PATH، أو استخدام nvm الذي يثبّت الحزم العامة تلقائيًا تحت مجلدك الشخصي.

كيف أُبقي Gemini CLI يعمل بعد أن أقطع الاتصال؟

شغّله داخل tmux. عملية بدأتها من صدفة SSH لديك تموت حين ينقطع الاتصال لأنها عملية تابعة لتلك الصدفة؛ أما tmux فيشغّل الصدفة تحت خادم منفصل ينجو من الانقطاع. استخدم tmux new -A -s gemini، وشغّل gemini بداخله، وافصل الجلسة بـ Ctrl-b d، وأعد الاتصال بها لاحقًا بالأمر tmux attach -t gemini.

هل من الآمن تشغيل Gemini CLI على خادم إنتاج؟

بحذر فقط، لأن وكيلًا يملك وصولًا إلى الصدفة يستطيع فعل أي شيء يستطيعه المستخدم الذي يعمل تحته. شغّله بمستخدم مخصص غير مميّز الصلاحيات وبلا sudo، وأبقِ بيانات اعتماد الإنتاج بعيدة عن الجهاز، وتجنّب الموافقة التلقائية --yolo، واستخدم --sandbox (عبر Docker أو Podman) لعزل استدعاءات الأدوات عن المضيف. الحساب الذي يعمل تحته أهم من أي خيار منفرد تضبطه.

هل أحتاج إلى فتح أي منافذ في جدار الحماية من أجل Gemini CLI؟

لا. إنه عميل يجري استدعاءات HTTPS صادرة نحو واجهات برمجة تطبيقات Google، فيحتاج المنفذ 443 الصادر فقط ولا يحتاج أي منافذ واردة. إن استخدمت نفق OAuth، فيبقى منفذ الاستدعاء الرجعي المثبَّت (لنقل 8085) على localhost ويُبلَغ عبر تمرير SSH لديك، لا عبر منفذ وارد مفتوح. أبقِ الوارد مغلقًا.