Gemini CLI auf Headless VPS installieren

Was Sie aufbauen

Ein permanent laufendes Gemini CLI auf einem eigenen Server, erreichbar über SSH. Es führt lang laufende Agenten-Aufgaben aus, die nach dem Schließen des Laptops weiterlaufen. Die Installation umfasst drei Befehle. Schwierig ist alles, was eine Desktop-Umgebung voraussetzt: Das Google CLI möchte einen Browser zum Login öffnen, aber Ihr Server besitzt keinen. Daher konzentriert sich dieser Leitfaden auf den Headless-Pfad – eine aktuelle Node-Version, die die Distribution nicht bereitstellt, eine globale npm-Installation ohne Root-Rechte, eine browserlose Authentifizierung mittels API-Key (der nicht in der Shell-Historie gespeichert wird) und tmux, damit eine unterbrochene SSH-Sitzung eine laufende Aufgabe nicht abbricht.

Gemini CLI ist ein Open-Source (Apache-2.0) Node-Programm (@google/gemini-cli), das mit Googles Gemini-Modellen kommuniziert. Es kann Dateien lesen und schreiben, Shell-Befehle ausführen und Tools im Arbeitsverzeichnis steuern. Auf einem VPS ist es ein kleiner, permanent verfügbarer Agent, den Sie zur Arbeit zurücklassen können. Daher sind das Benutzerkonto, unter dem er läuft, und die auf dem System gespeicherten Anmeldedaten wichtiger als jede einzelne Einstellung in dieser Anleitung.

Voraussetzungen und bekannte Fallstricke

• Ein frisches Ubuntu 24.04 KVM VPS mit root- oder sudo-Rechten. Jeder KVM-Tarif ist geeignet; das CLI ist sehr leichtgewichtig und benötigt im Leerlauf nur wenige hundert MB RAM.
• Node.js 20 oder neuer. Dies ist die einzige strikte Versionsvoraussetzung. Das Standardpaket der Distribution ist älter — siehe den nächsten Abschnitt.
• Ausgehender HTTPS-Zugriff (Port 443) auf die Google-APIs. Es sind keine eingehenden Ports erforderlich; da es sich um einen Client handelt, muss keine Firewall-Regel geöffnet werden.
• Eine Authentifizierungsmethode, die keinen Browser auf dem Server erfordert: Entweder ein Gemini API-Key aus dem Google AI Studio oder ein SSH-Tunnel zu einem Browser auf Ihrem lokalen Rechner. Die API-Key-Methode eignet sich für Skripte und automatisierte Abläufe.
• Docker oder Podman, falls Sie die --sandbox Isolation nutzen möchten. Optional, wird am Ende behandelt.

Der häufigste Fehler: Der gemini Login-Flow beim ersten Start ist für Desktop-Systeme konzipiert. Er versucht, einen Browser zu öffnen. Auf einem Headless-System schlägt dies fehl oder liefert einen Link, der nicht funktioniert. Entscheiden Sie sich vor Beginn für einen Authentifizierungspfad.

Node: Das Distro-Paket ist zu alt

Ubuntu 24.04 liefert Node 18.19.1 aus den eigenen Repositories mit npm 9.2.0 aus. Die package.json von Gemini CLI setzt engines: { node: ">=20" } voraus. npm verhindert eine Versionsdiskrepanz standardmäßig nicht; es installiert das Paket trotzdem und gibt eine Warnung aus, die die Differenz benennt:

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 }

Ignorieren Sie diese Warnung und die CLI läuft auf einer nicht unterstützten Runtime. Dies führt zu Fehlfunktionen oder Abstürzen, sobald die CLI auf eine Node 20+ API zugreift, die vorhanden sein muss. Node 18 hat zudem im April 2025 das End-of-Life erreicht und ist somit ohnehin nicht mehr nutzbar. Installieren Sie eine aktuelle LTS-Version, bevor Sie die CLI installieren. Es gibt zwei saubere Wege: NodeSource (ein systemweites, signiertes apt-Repo) oder nvm (ein Versionsmanager pro Benutzer). Wählen Sie einen dieser Wege.

NodeSource, wenn Node für jeden Benutzer auf dem System verfügbar sein soll:

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 muss v20.x oder höher ausgeben — v24.x ist die aktuelle aktive LTS. Prüfen Sie die NodeSource-Seite auf das aktuelle Setup-Skript; die setup_24.x in der URL muss angepasst werden, wenn eine neue LTS erscheint.

nvm, wenn Node nur im Home-Verzeichnis eines Benutzers installiert werden soll und ohne sudo verwaltet werden soll:

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

Die v0.40.1 in dieser URL war zum Zeitpunkt der Erstellung aktuell; prüfen Sie die README von nvm auf die neueste Version und ersetzen Sie die Versionsnummer, bevor Sie den Befehl ausführen. nvm bietet hier einen Vorteil: Node und die globalen Pakete werden unter ~/.nvm installiert. Das Berechtigungsproblem bei globalen Installationen im nächsten Abschnitt tritt dadurch nicht auf. Wenn Sie nvm verwenden, können Sie den Schritt mit dem npm-prefix überspringen.

Installieren Sie das CLI ohne sudo npm -g

Der verlockende Befehl ist sudo npm install -g @google/gemini-cli. Lassen Sie dies. Ein globaler Prefix unter Root-Rechten verursacht bei jeder späteren Installation Berechtigungsfehler. Zudem verbleiben Root-gehörige Dateien in Ihrem npm-Cache, die erst Monate später Probleme verursachen. Führen Sie ein einfaches (ohne sudo) npm install -g gegen ein System-Node aus, und Sie erhalten den anderen Fehler:

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 versucht hier, in /usr/lib zu schreiben, worauf Ihr Benutzer keinen Zugriff hat. Die Lösung ist nicht sudo. Sie besteht darin, den globalen Prefix von npm auf Ihr Home-Verzeichnis zu setzen. So landen globale Installationen an einem Ort, an dem Sie die Rechte besitzen:

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 statt ~/.profile ist beabsichtigt: tmux — welches Sie zwei Abschnitte später für das CLI nutzen werden — startet eine Non-Login-Shell. Diese liest ~/.bashrc und ignoriert ~/.profile. Eine PATH Zeile in der falschen Datei führt dazu, dass gemini genau dort unsichtbar bleibt, wo sie benötigt wird. Der Test besteht darin, ob gemini --version eine Versionsnummer ausgibt. Wenn Sie stattdessen gemini: command not found erhalten, wurde Ihr PATH Export nicht übernommen — siehe die Fehlerursachen. Bei der Verwendung von nvm können Sie die Prefix-Zeilen komplett überspringen, da nvm globale Pakete bereits unter Ihrem Home installiert.

Falls Sie sudo npm zu einem früheren Zeitpunkt ausgeführt haben und nun Your cache folder contains root-owned files sehen, beheben Sie dies mit sudo chown -R $(id -u):$(id -g) ~/.npm.

Das Headless-Authentifizierungsproblem und dessen Lösung

Führen Sie gemini beim ersten Mal interaktiv aus. Das Programm bietet an, Sie mit Ihrem Google-Konto anzumelden. Auf einem Desktop wird ein Browser-Tab geöffnet. Auf einem Headless-VPS gibt es keinen Browser. Der Prozess gibt entweder eine localhost-URL aus, die Sie öffnen müssen, oder er schlägt mit einer Fehlermeldung wie dieser fehl:

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

Die Schwierigkeit liegt bei redirect_uri=http://localhost:PORT. Selbst wenn Sie die URL auf Ihrem Laptop öffnen und bestätigen, leitet Google zu http://localhost:PORT weiter – localhost auf dem Server. Dies ist ein Port, der von Ihrem Laptop aus nicht erreichbar ist. Die Anmeldung schlägt fehl.

Es gibt zwei zuverlässige Methoden.

Die erste Methode ist ein API-Key; dies ist die korrekte Standardmethode für Server. Erstellen Sie einen Key im Google AI Studio (aistudio.google.com) und übergeben Sie ihn der CLI als Umgebungsvariable. Die CLI liest GEMINI_API_KEY und überspringt den Browser-Prozess vollständig. Beachten Sie dabei die Sicherheit: Geben Sie export GEMINI_API_KEY=AIza... nicht direkt in der Eingabeaufforderung ein. Der Key wird im Klartext in ~/.bash_history gespeichert. Speichern Sie den Key zudem nicht in einer Datei, die für andere lesbar ist. Schreiben Sie ihn in eine Datei mit den Rechten 600, die die Shell beim Start lädt:

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 bedeutet, dass nur Ihr Benutzer die Datei lesen kann. Überprüfen Sie mit printenv GEMINI_API_KEY, ob der Key in der Umgebung geladen wurde. Wenn die Ausgabe leer ist, nutzt die CLI den Browser-Prozess und schlägt fehl. Die CLI liest bei dieser Struktur auch eine .env-Datei in ~/.gemini/, falls Sie dieses Layout bevorzugen. Es gilt dieselbe Regel: nutzen Sie chmod 600 ~/.gemini/.env.

Die zweite Methode nutzt die Anmeldung über das persönliche Google-Konto (und den kostenlosen Tarif), indem der OAuth-Callback an Ihren Laptop tunnelbar gemacht wird. Das Problem ist, dass der Loopback-Server der CLI bei jedem Durchlauf einen zufälligen Port bindet. Es gibt keinen stabilen Port zum Weiterleiten, es sei denn, Sie fixieren ihn zuerst mit der Umgebungsvariable OAUTH_CALLBACK_PORT und leiten dann genau diesen Port weiter:

# 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

Die CLI kann keinen Browser öffnen und gibt daher die Auth-URL aus. Öffnen Sie diese in Ihrem Laptop-Browser und bestätigen Sie die Anmeldung. Wenn Google zu http://localhost:8085/... weiterleitet, leitet die SSH-Weiterleitung die Anfrage an den Loopback-Server auf dem VPS weiter und die Anmeldung wird abgeschlossen. Wenn der Port nicht fixiert ist, wird bei jedem Durchgang ein neuer zufälliger Port verwendet. Diesen kann keine vorherige ssh -L abfangen. Diese Methode funktioniert, erfordert aber manuelle Interaktion im Browser und ist daher nicht für Skripte geeignet. Verwenden Sie für alle dauerhaften Prozesse den API-Key.

Für Vertex AI oder ein Google Cloud Projekt anstelle von AI Studio setzen Sie GOOGLE_API_KEY zusammen mit GOOGLE_GENAI_USE_VERTEXAI=true oder GOOGLE_CLOUD_PROJECT für eine Code Assist Lizenz. Es gelten dieselben Regeln für Umgebungsvariablen und Dateien mit den Rechten 600.

Führen Sie es in tmux aus, damit eine unterbrochene SSH-Sitzung den Prozess nicht beendet

Ein gemini Prozess, den Sie direkt über Ihre SSH-Shell starten, ist ein Kindprozess dieser Shell. Wenn die Verbindung verloren geht — durch zuklappen des Laptops, WLAN-Ausfall oder einen Idle-Timeout — zerstört sshd das Pseudo-Terminal. Die Shell erhält SIGHUP und beendet die CLI-Sitzung. Ein Task, der bereits zehn Minuten lang Dateien bearbeitet hat, wird dadurch beendet, und nach einer erneuten Verbindung ist der Prozess nicht mehr wiederherstellbar.

tmux löst dieses Problem, indem es die Shell übernimmt, anstatt dass sshd diese besitzt. Dies entspricht dem gleichen Muster wie das Ausführen eines AI-Coding-Agents auf einem Remote-VPS innerhalb von tmux, und es funktioniert hier identisch:

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 verbindet sich mit einer Sitzung namens gemini, falls diese existiert, oder erstellt sie, falls nicht. Dies ist der einzige Befehl, der direkt nach jedem Login ausgeführt werden sollte. Die Shell innerhalb von tmux gehört dem getrennten tmux-Server und nicht Ihrer SSH-Sitzung. Daher bleibt die CLI aktiv, wenn die Verbindung abbricht. Nach einer erneuten Verbindung und dem Befehl zum Verbinden (attach) befinden Sie sich wieder im selben Scrollback-Verlauf.

Für nicht-interaktive, skriptbasierte Ausführungen bietet Gemini CLI einen Headless-Modus: gemini -p "summarise the failing tests in this repo" gibt eine Antwort aus und beendet sich, und --output-format json liefert maschinenlesbare Ausgaben für die Weiterleitung (pipe) an andere Programme. Der Headless-Modus mit einem API-Key ist ideal für tmux-Sitzungen, die lange Batch-Jobs ausführen, oder für Aufgaben, die über einen cron-Eintrag gestartet werden. Es gibt jedoch eine Einschränkung: Ein cron-Job lädt keine Ihrer Login-Dateien. Geben Sie der crontab-Zeile daher eine eigene GEMINI_API_KEY (oder lassen Sie den Befehl ~/.gemini_env laden), da die CLI sonst auf den Browser-Flow zurückgreift und fehlschlägt.

Sandboxing und Berechtigungen auf einem System mit Produktionsbetrieb

Ein Agent mit Shell-Zugriff ist eine Shell. Gemini CLI kann Befehle ausführen. Standardmäßig fragt das Tool vor jedem riskanten Befehl nach. Nutzer verwenden jedoch oft --yolo (automatische Genehmigung jedes Tool-Aufrufs). In diesem Fall kann der Agent Dateien löschen, Änderungen zu git pushen oder interne Dienste mit den vollen Berechtigungen des jeweiligen Benutzers aufrufen. Auf einem System, das auch Produktion betreibt, ist dies ein realer Schadensradius und kein hypothetisches Szenario.

Drei Sicherheitsmaßnahmen, sortiert nach ihrem Nutzen:

• Ausführung als dedizierter, unprivilegierter Benutzer. Nicht als root und nicht als Mitglied von sudo. Erstellen Sie einen agent-Benutzer mit einem eigenen Home-Verzeichnis. Installieren Sie Node und das CLI dort. So bleibt ein fehlerhafter Befehl auf dieses Konto beschränkt. Dies ist die wichtigste Sicherheitsmaßnahme.
• Keine Produktions-Credentials auf dem System speichern. Keine Prod-~/.aws/credentials, keine von der Produktion kopierten .env und keine Datenbank-Passwörter mit Schreibrechten auf kritische Daten. Verwenden Sie Staging- oder Read-Only-Credentials.
• Den integrierten Sandbox-Modus nutzen. Wenn Docker oder Podman installiert sind, führt gemini --sandbox (oder GEMINI_SANDBOX=docker) die Tool-Aufrufe des Agents in einem Container aus. Dieser ist vom Dateisystem und Netzwerk des Hosts isoliert. Dies ersetzt den unprivilegierten Benutzer nicht, bietet aber eine starke zweite Sicherheitsebene, wenn derselbe VPS produktive Aufgaben übernimmt.

Wenn Sie Gemini CLI neben anderen selbst gehosteten Tools ausführen – zum Beispiel einen MCP-Server, der dem Agenten auf demselben VPS Tools bereitstellt – betrachten Sie jede zusätzliche Funktion als eine Erweiterung der Angriffsfläche. Beschränken Sie die zugewiesenen Tokens exakt auf eine einzige Aufgabe.

Kontingent, Kosten und gewählter Authentifizierungspfad

Der Authentifizierungspfad bestimmt die Abrechnungsmethode. Ein privates Google-Konto (OAuth-Pfad) nutzt die kostenlose Gemini Code Assist-Stufe mit festen Limits pro Minute und Tag; bei Überschreitung dieser Limits geben Anfragen einen Rate-Limit-Fehler zurück, bis das Zeitfenster zurückgesetzt wird. Ein API-Key aus dem AI Studio kann je nach Projekt kostenlos sein oder abgerechnet werden – ein kostenpflichtiger Key erhöht die Limits und berechnet die Kosten pro Token. Die Authentifizierung über Vertex oder ein Cloud-Projekt erfolgt über Google Cloud.

Zwei praktische Hinweise. Ein Agent, der in einer Schleife ohne Benutzerinteraktion läuft, kann das Kontingent schnell erschöpfen. Überwachen Sie den Agenten daher bei den ersten Durchläufen, bevor Sie ihn in einem cron-Job automatisieren. Und wenn Sie ein serverseitiges Modell aus Datenschutzgründen oder für unbegrenzte Inferenz anstelle der gehosteten Modelle von Google nutzen möchten, ist dies ein anderes Werkzeug – das Self-Hosting eines Open-LLM mit Ollama auf einem VPS speichert die Gewichte und die Prompts auf Ihrem eigenen System, allerdings auf Kosten der Nutzung eines deutlich kleineren Modells als Gemini.

Aktualisierung auf dem neuesten Stand halten

Gemini CLI wird häufig aktualisiert. Da Sie es in einem Benutzer-Prefix installiert haben, sind keine sudo-Befehle für Updates erforderlich:

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

Es gibt verschiedene Release-Kanäle: @latest ist die stabile Version, @preview ist die wöchentliche Vorschau und @nightly ist die Version mit den neuesten Funktionen. Nutzen Sie für produktive Systeme @latest. Bei der Verwendung von nvm werden globale Pakete unter der aktiven Node-Version gespeichert. Wenn Sie mit nvm use die Node-Version wechseln, müssen Sie das CLI möglicherweise neu installieren. Lesen Sie die Release Notes, anstatt jedem Patch hinterherzulaufen.

Fehlerursachen und exakte Fehlermeldungen

npm WARN EBADENGINE Unsupported engine ... required: { node: '>=20' }, gefolgt von einem CLI-Absturz zur Laufzeit. Node ist zu alt — die Distribution nutzt Version 18.19.1, die das End-of-Life erreicht hat. Installieren Sie Node 20+ über NodeSource oder nvm. Überprüfen Sie dies mit node --version. Falls mehrere Node-Versionen installiert sind, stellen Sie sicher, dass which node auf die neue Version und nicht auf /usr/bin/node zeigt.

npm error code EACCES / permission denied, mkdir '/usr/lib/node_modules/...'. Eine globale Installation in einen Root-geschützten Prefix. Verwenden Sie kein sudo — setzen Sie npm config set prefix ~/.npm-global, setzen Sie ~/.npm-global/bin auf PATH und installieren Sie die Software als normaler Benutzer neu. Falls eine frühere sudo npm Root-geschützte Cache-Dateien (Your cache folder contains root-owned files) hinterlassen hat, führen Sie sudo chown -R $(id -u):$(id -g) ~/.npm aus.

Failed to open browser, ein hängender Login oder ein redirect_uri=http://localhost:PORT, der nicht erreichbar ist. Der OAuth-Flow benötigt einen Browser, der auf dem Server nicht vorhanden ist. Zudem zeigt der Localhost-Callback auf den Server und nicht auf Ihren Laptop. Nutzen Sie den API-Key-Pfad (GEMINI_API_KEY) oder fixieren Sie OAUTH_CALLBACK_PORT. Leiten Sie den Traffic via SSH mit ssh -L weiter und öffnen Sie die URL lokal.

Der Prozess wurde durch eine getrennte SSH-Verbindung beendet. Sie haben gemini direkt in der SSH-Shell ausgeführt. Der Prozess war ein Child-Prozess der Shell und wurde beim Trennen der pty beendet. Es gibt nichts wiederherzustellen. Starten Sie jede Sitzung mit tmux new -A -s gemini und führen Sie die CLI darin aus.

Die Authentifizierung schlägt trotz gesetztem Key fehl — die CLI kehrt zur Auswahl der Authentifizierungsmethode zurück oder eine Anfrage liefert API key not valid mit HTTP 400. Der Key ist in der Umgebung der CLI nicht vorhanden. Prüfen Sie dies mit printenv GEMINI_API_KEY. Falls die Variable leer ist, wurde ~/.gemini_env nicht geladen — prüfen Sie, ob die Zeile in ~/.bashrc steht. Interaktive Shells (einschließlich tmux) lesen diese Datei, cron und andere nicht-interaktive Shells jedoch nicht. Ein versehentliches Leerzeichen oder Anführungszeichen innerhalb des Key-Werts verursacht ebenfalls API key not valid.

429 / RESOURCE_EXHAUSTED / eine Rate-Limit-Meldung. Das Kontingent für die genutzte Authentifizierungsstufe wurde überschritten. Warten Sie, bis das Zeitfenster zurückgesetzt wird, drosseln Sie die Agent-Geschwindigkeit oder nutzen Sie einen kostenpflichtigen API-Key. Ein Agent in einer Retry-Schleife verursacht diesen Fehler fortlaufend — stoppen Sie den Agenten und prüfen Sie dessen Aktivitäten.

FAQ

Wie authentifiziere ich Gemini CLI auf einem Headless-Server?

Verwenden Sie einen API-Key anstatt des Browser-Logins. Erstellen Sie einen Key im Google AI Studio, speichern Sie diesen in einer Datei mit den Rechten 600, die von Ihrer Shell geladen wird (export GEMINI_API_KEY=...), und das CLI überspringt den OAuth-Browser-Flow vollständig. Wenn Sie explizit den kostenlosen Tarif für Privatkonten nutzen möchten, fixieren Sie den Loopback-Port mit OAUTH_CALLBACK_PORT=8085, leiten Sie diesen mit ssh -L 8085:localhost:8085 user@server an Ihren Laptop weiter und öffnen Sie die ausgegebene URL lokal — dies erfordert jedoch die Interaktion in einem Browser und ist daher nicht für Skripte geeignet.

Warum erfordert die globale npm-Installation sudo und wie vermeide ich das?

Weil der Standard-Global-Prefix von npm /usr/lib/node_modules ist, auf den Ihr Benutzer keine Schreibrechte hat. Ein einfacher Befehl npm install -g schlägt daher mit EACCES fehl. Die falsche Lösung ist sudo npm -g, da dies Dateien mit Root-Besitz hinterlässt, die spätere Installationen blockieren. Die korrekte Lösung besteht darin, den Prefix auf Ihr Home-Verzeichnis (npm config set prefix ~/.npm-global) zu setzen und dessen bin zu PATH hinzuzufügen, oder nvm zu verwenden, welches globale Pakete automatisch unter Ihrem Home-Verzeichnis installiert.

Wie lasse ich Gemini CLI nach der Trennung der Verbindung weiterlaufen?

Führen Sie es innerhalb von tmux aus. Ein Prozess, der in Ihrer SSH-Shell gestartet wurde, wird beendet, wenn die Verbindung abbricht, da er ein Kindprozess dieser Shell ist; tmux führt die Shell unter einem getrennten Server aus, der die Trennung überlebt. Nutzen Sie tmux new -A -s gemini, starten Sie gemini darin, trennen Sie die Sitzung mit Ctrl-b d und stellen Sie sie später mit tmux attach -t gemini wieder her.

Ist es sicher, Gemini CLI auf einem Produktionssystem auszuführen?

Nur mit Vorsicht, da ein Agent mit Shell-Zugriff alle Berechtigungen des ausführenden Benutzers besitzt. Führen Sie es als dedizierten, unprivilegierten Benutzer ohne sudo-Rechte aus, speichern Sie keine Produktions-Credentials auf der Maschine, vermeiden Sie die automatische Bestätigung durch --yolo und nutzen Sie --sandbox (Docker oder Podman), um Tool-Aufrufe vom Host zu isolieren. Das Konto, unter dem der Prozess läuft, ist wichtiger als jeder einzelne Flag.

Muss ich Firewall-Ports für Gemini CLI öffnen?

Nein. Es handelt sich um einen Client, der ausgehende HTTPS-Aufrufe an die Google-APIs sendet. Er benötigt den ausgehenden Port 443, aber keine eingehenden Ports. Wenn Sie den OAuth-Tunnel verwenden, befindet sich der fixierte Callback-Port (z. B. 8085) auf localhost und wird über Ihre SSH-Weiterleitung erreicht, nicht über einen offenen eingehenden Port. Halten Sie die eingehenden Verbindungen geschlossen.