Gemini CLI auf einem Headless-VPS ausführen

Was Sie aufbauen

Eine dauerhaft laufende Gemini CLI auf einem Server, den Sie selbst verwalten. Sie greifen über SSH darauf zu. Die CLI führt lang laufende Agent-Aufgaben aus, die auch dann weiterlaufen, wenn Sie den Laptop schließen. Für die Installation benötigen Sie drei Befehle. Der eigentliche Aufwand liegt in allem, was eine Desktop-Umgebung voraussetzt: Die CLI von Google möchte zum Anmelden einen Browser öffnen. Auf Ihrem Server ist jedoch kein Browser vorhanden. Deshalb behandelt der größte Teil dieser Anleitung den Betrieb ohne grafische Oberfläche, eine aktuelle Node-Version, die die Distribution nicht bereitstellt, eine globale npm-Installation ohne root, die Anmeldung ohne Browser mit einem API-Schlüssel, der nicht in der Shell-History landet, sowie tmux, damit eine getrennte SSH-Sitzung keine laufende Aufgabe beendet.

Gemini CLI ist ein Open-Source-Programm (Apache-2.0) für Node (@google/gemini-cli). Es kommuniziert mit den Gemini-Modellen von Google, kann Dateien lesen und schreiben, Shell-Befehle ausführen und Tools im Arbeitsverzeichnis steuern. Auf einem VPS ist es ein kleiner, jederzeit verfügbarer Agent, den Sie laufend arbeiten lassen können. Deshalb sind das Konto, unter dem er ausgeführt wird, und die auf dem Server gespeicherten Zugangsdaten wichtiger als jede einzelne Einstellung in dieser Anleitung.

Voraussetzungen und wichtige Einschränkungen

• Ein frischer Ubuntu-24.04-KVM-VPS mit root oder sudo. Jeder KVM-Tarif funktioniert. Die CLI selbst benötigt wenig Ressourcen und belegt im Leerlauf einige hundert MB RAM.
• Node.js 20 oder neuer. Dies ist die einzige feste Mindestversion. Das Distributionspaket liegt darunter. Siehe den nächsten Abschnitt.
• Ausgehendes HTTPS (Port 443) zu den APIs von Google. Es sind keine eingehenden Ports erforderlich. Dies ist ein Client und kein Server. Sie müssen dafür keine Firewall-Öffnung einrichten.
• Eine Authentifizierungsmethode, die keinen Browser auf dem Server benötigt: entweder ein Gemini-API-Key aus Google AI Studio oder ein SSH-Tunnel zu einem Browser auf Ihrem eigenen Rechner. Die API-Key-Variante eignet sich für Skripte und unbeaufsichtigte Ausführungen.
• Docker oder Podman, nur wenn Sie die --sandbox-Isolation verwenden möchten. Dies ist optional und wird weiter unten behandelt.

Die Einschränkung, über die viele stolpern: Der benutzerfreundliche gemini-Anmeldevorgang beim ersten Start ist für einen Desktop ausgelegt. Er versucht, einen Browser zu öffnen. Auf einem Headless-System schlägt das entweder fehl, oder Sie erhalten einen Link, der nicht funktioniert. Legen Sie den Authentifizierungsweg fest, bevor Sie beginnen.

Die Distributionspakete für Node sind zu alt

Ubuntu 24.04 stellt in den eigenen Paketquellen Node 18.19.1 zusammen mit npm 9.2.0 bereit. Die package.json von Gemini CLI gibt engines: { node: ">=20" } vor. npm bricht bei einer Abweichung standardmäßig nicht sofort ab. Stattdessen wird die Installation fortgesetzt und eine Warnung ausgegeben, die den Unterschied nennt:

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 }

Wenn Sie diese Warnung ignorieren, läuft die CLI auf einer nicht unterstützten Runtime. Sie verhält sich fehlerhaft oder stürzt ab, sobald sie eine Node-20+-API verwendet, deren Vorhandensein sie voraussetzt. Node 18 hat außerdem im April 2025 das Supportende erreicht. Diese Version ist daher unabhängig davon keine geeignete Option. Installieren Sie eine aktuelle LTS-Version, bevor Sie die CLI installieren. Dafür gibt es zwei saubere Wege: NodeSource, ein systemweit verfügbares signiertes apt-Repository, oder nvm, ein Versionsmanager pro Benutzer. Wählen Sie einen davon.

NodeSource, wenn Node für alle 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 aktuell aktive LTS-Version. Prüfen Sie die NodeSource-Seite auf das aktuelle Einrichtungsskript. setup_24.x in der URL bezeichnet die Stelle, die Sie anpassen müssen, sobald eine neuere LTS-Version veröffentlicht wird.

nvm, wenn Node im Home-Verzeichnis eines Benutzers bleiben und niemals mit sudo verändert werden soll:

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 in dieser URL war beim Verfassen dieses Textes aktuell. Prüfen Sie die README von nvm auf die neueste Version und ersetzen Sie die Versionsnummer, bevor Sie das Skript ausführen. nvm bietet für diese Aufgabe einen konkreten Vorteil: Node und seine globalen Pakete werden unter ~/.nvm installiert. Das Berechtigungsproblem bei globalen Installationen aus dem nächsten Abschnitt tritt dadurch nicht auf. Wenn Sie nvm verwenden, können Sie den Schritt zum Setzen des npm-Präfixes überspringen.

CLI ohne sudo npm -g installieren

Der naheliegende Befehl ist sudo npm install -g @google/gemini-cli. Verwenden Sie ihn nicht. Ein globales, root-eigenes Präfix führt bei jeder späteren Installation zu Berechtigungsfehlern. Außerdem bleiben root-eigene Dateien in Ihrem npm-Cache zurück, die Ihnen noch Monate später Probleme bereiten. Wenn Sie ein einfaches (ohne sudo) npm install -g mit einem systemweiten Node ausführen, tritt der andere Fehler auf:

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 dabei, in /usr/lib zu schreiben. Ihr Benutzer hat dort keine Berechtigung. Die Lösung ist nicht sudo. Setzen Sie stattdessen das globale Präfix von npm auf Ihr Home-Verzeichnis. Dann landen globale Installationen an einem Ort, den Sie 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 und nicht ~/.profile ist beabsichtigt. tmux, in dem Sie die CLI zwei Abschnitte später ausführen, startet eine Nicht-Login-Shell. Diese liest ~/.bashrc und überspringt ~/.profile. Eine PATH-Zeile in der falschen Datei lässt gemini genau dort unsichtbar, wo Sie es benötigen. Wenn gemini --version eine Versionsnummer ausgibt, ist der Test abgeschlossen. Erhalten Sie stattdessen gemini: command not found, wurde Ihr PATH-Export nicht übernommen. Weitere Informationen finden Sie unter den Fehlerursachen. Bei nvm überspringen Sie die Präfixzeilen vollständig. nvm installiert globale Pakete bereits unter Ihrem Home-Verzeichnis.

Wenn Sie zuvor sudo npm ausgeführt haben und jetzt Your cache folder contains root-owned files sehen, beheben Sie das einmalig mit sudo chown -R $(id -u):$(id -g) ~/.npm.

Das Headless-Authentifizierungsproblem und wie Sie es umgehen

Führen Sie gemini beim ersten Mal interaktiv aus. Das Programm bietet dann die Anmeldung mit Ihrem Google-Konto an. Auf einem Desktop wird ein Browser-Tab geöffnet. Auf einem Headless-VPS ist kein Browser verfügbar. Daher gibt der Ablauf entweder eine localhost-URL aus, die Sie öffnen sollen, oder schlägt direkt mit einer Meldung 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 Ursache ist redirect_uri=http://localhost:PORT. Auch wenn Sie die URL auf Ihrem Laptop öffnen und den Zugriff bestätigen, leitet Google zu http://localhost:PORT weiter. Das ist localhost auf dem Server. Kein Prozess auf Ihrem Laptop kann diesen Port erreichen. Die Anmeldung wird nicht abgeschlossen.

Es gibt zwei praktikable Wege.

Der erste Weg ist ein API-Schlüssel. Für einen Server ist das die empfohlene Standardeinstellung. Erstellen Sie in Google AI Studio (aistudio.google.com) einen Schlüssel und übergeben Sie ihn dem CLI als Umgebungsvariable. Das CLI liest GEMINI_API_KEY und überspringt den Browser-Ablauf vollständig. Nun zum Schutz vor Einträgen in der Shell-History und vor Dateien mit weltweiten Leserechten: Geben Sie export GEMINI_API_KEY=AIza... nicht an der Eingabeaufforderung ein. Der Wert landet dort unverschlüsselt in ~/.bash_history. Speichern Sie ihn auch nicht in einer Datei, die andere Benutzer lesen können. Schreiben Sie ihn in eine Datei mit Modus 600, die die Shell beim Start einliest:

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. Prüfen Sie mit printenv GEMINI_API_KEY, ob der Schlüssel in der Umgebung angekommen ist. Wenn keine Ausgabe erfolgt, verwendet das CLI wieder den Browser-Ablauf, der auf dem Server fehlschlägt. Das CLI liest außerdem eine .env-Datei in ~/.gemini/, wenn Sie diese Struktur bevorzugen. Die gleiche Regel gilt: chmod 600 ~/.gemini/.env.

Der zweite Weg behält die Anmeldung mit dem persönlichen Google-Konto und dessen kostenloses Kontingent bei. Dazu tunneln Sie den OAuth-Callback zurück zu Ihrem Laptop. Der Nachteil: Der Loopback-Server des CLI bindet bei jedem Lauf an einen zufälligen Port. Es gibt daher keinen festen Port, den Sie weiterleiten können. Legen Sie den Port zuerst mit der Umgebungsvariable OAUTH_CALLBACK_PORT fest. Leiten Sie anschließend 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

Das CLI kann keinen Browser öffnen und gibt daher die Authentifizierungs-URL aus. Öffnen Sie sie im Browser Ihres Laptops und bestätigen Sie den Zugriff. Wenn Google zu http://localhost:8085/... weiterleitet, transportiert die SSH-Weiterleitung die Anfrage zum Loopback-Server auf dem VPS. Die Anmeldung wird abgeschlossen. Wenn Sie den Port nicht festlegen, wird bei jedem Lauf ein neuer zufälliger Port verwendet. Eine Weiterleitung, die mit ssh -L im Voraus eingerichtet wurde, kann diesen Port nicht erreichen. Dieser Weg funktioniert, erfordert aber einen Browser und Ihre Anwesenheit. Für Skripte ist er daher ungeeignet. Für dauerhaft laufende Prozesse sollten Sie den API-Schlüssel verwenden.

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. Für eine Code Assist-Lizenz verwenden Sie GOOGLE_CLOUD_PROJECT. Auch hier gelten dieselben Regeln für Umgebungsvariablen und eine Datei mit Modus 600.

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

Ein gemini-Prozess, den Sie direkt aus Ihrer SSH-Shell starten, ist ein Kindprozess dieser Shell. Wenn die Verbindung verloren geht, der Laptop geschlossen wird, das WLAN ausfällt oder ein Leerlauf-Timeout eintritt, baut sshd das Pseudo-Terminal ab. Die Shell empfängt SIGHUP und beendet daraufhin auch die CLI. Eine Aufgabe, die seit zehn Minuten Dateien bearbeitet, wird dadurch ebenfalls beendet. Nach der erneuten Anmeldung gibt es keinen Prozess, den Sie wieder aufnehmen können.

tmux löst dieses Problem, indem es die Shell besitzt, statt dass sshd sie besitzt. Dies entspricht dem Muster einen KI-Coding-Agent auf einem entfernten VPS innerhalb von tmux auszuführen und funktioniert hier genauso:

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 Sie mit einer Sitzung namens gemini, wenn diese existiert, und erstellt sie andernfalls. Deshalb ist dies der eine Befehl, den Sie direkt nach jeder Anmeldung ausführen sollten. Die darin ausgeführte Shell gehört zum getrennten tmux-Server und nicht zu Ihrer SSH-Sitzung. Wenn die Verbindung abbricht, arbeitet die CLI weiter. Melden Sie sich erneut an, verbinden Sie sich mit der Sitzung, und Sie sehen wieder denselben Scrollback. Wenn Sie mehrere Agent-Sitzungen auf einem System ausführen, verwenden Sie jeweils eine eigene tmux-Sitzung. Diese Sitzungen können hier nicht miteinander kommunizieren. Das ist anders als bei Claude Code, bei dem eine Sitzung Text an eine andere auf demselben VPS übergeben kann. Lassen Sie daher jeden Gemini-Auftrag unabhängig arbeiten oder koordinieren Sie die Aufträge über Dateien auf dem Datenträger.

Für nicht interaktive, skriptgesteuerte Ausführungen bietet Gemini CLI einen Headless-Modus: gemini -p "summarise the failing tests in this repo" gibt eine Antwort aus und beendet sich, während --output-format json eine maschinenlesbare Ausgabe zum Weiterleiten an andere Prozesse erzeugt. Der Headless-Modus mit einem API-Schlüssel eignet sich genau für eine tmux-Sitzung, in der ein langer Batch-Auftrag läuft, oder für den Start aus einem cron-Eintrag. Es gibt jedoch eine Einschränkung: Ein cron-Auftrag liest keine Ihrer Login-Dateien ein. Geben Sie der crontab-Zeile daher eine eigene GEMINI_API_KEY mit, oder lassen Sie den Befehl ~/.gemini_env einlesen. Andernfalls wechselt die CLI auf den Browser-Flow und schlägt fehl.

Sandboxing und Berechtigungen auf einem Server, auf dem auch produktive Dienste laufen

Ein Agent mit Shell-Zugriff ist eine Shell. Gemini CLI kann Befehle ausführen. Standardmäßig fragt es vor jedem riskanten Befehl nach. Trotzdem verwenden Benutzer schnell --yolo (automatische Genehmigung jedes Tool-Aufrufs). Dann kann der Agent Dateien löschen, Änderungen zu git pushen oder interne Dienste mit den vollständigen Berechtigungen des Benutzerkontos aufrufen, unter dem er läuft. Auf einem Server, auf dem auch produktive Dienste laufen, ist das ein realer Schadensradius und keine theoretische Möglichkeit.

Drei Maßnahmen, geordnet nach ihrem Nutzen:

• Führen Sie den Agenten unter einem eigenen, nicht privilegierten Benutzerkonto aus. Verwenden Sie weder root noch ein Mitglied von sudo. Erstellen Sie einen agent-Benutzer mit eigenem Home-Verzeichnis und installieren Sie Node sowie die CLI dort. Eine falsch interpretierte Anweisung bleibt dann auf dieses Konto beschränkt. Dies ist die wichtigste Einzelentscheidung.
• Halten Sie Produktionszugangsdaten vom Server fern. Keine produktiven ~/.aws/credentials, keine aus der Produktion kopierten .env und kein Datenbankpasswort mit Schreibzugriff auf relevante Systeme. Verwenden Sie Zugangsdaten für Staging oder mit Nur-Lese-Berechtigung.
• Verwenden Sie die integrierte Sandbox. Wenn Docker oder Podman installiert ist, führt gemini --sandbox (oder GEMINI_SANDBOX=docker) die Tool-Aufrufe des Agenten in einem Container aus, der vom Dateisystem und Netzwerk des Hosts isoliert ist. Dies ersetzt den nicht privilegierten Benutzer nicht, bildet aber eine starke zweite Schutzschicht, wenn auf derselben VPS produktive Dienste laufen.

Wenn Sie Gemini CLI neben anderen selbst gehosteten Diensten ausführen, beispielsweise neben einem MCP-Server, der dem Agenten auf derselben VPS Tools bereitstellt, sollten Sie jede zusätzliche Funktion als weitere Angriffsfläche betrachten, auf die der Agent zugreifen kann. Beschränken Sie die übergebenen Tokens genau auf eine Aufgabe.

Kontingent, Kosten und der gewählte Authentifizierungspfad

Der Authentifizierungspfad bestimmt, wie die Abrechnung erfolgt. Ein persönliches Google-Konto (der OAuth-Pfad) verwendet die kostenlose Gemini Code Assist-Stufe mit tatsächlichen Limits pro Minute und pro Tag. Werden diese überschritten, geben Anfragen bis zum Zurücksetzen des Zeitfensters einen Rate-Limit-Fehler zurück. Ein API-Schlüssel aus AI Studio kann je nach Projekt zur kostenlosen Stufe gehören oder abgerechnet werden. Ein abgerechneter Schlüssel erhöht die Limits und berechnet die Nutzung pro Token. Bei der Authentifizierung über Vertex und ein Cloud-Projekt erfolgt die Abrechnung über Google Cloud.

Zwei praktische Hinweise. Ein unbeaufsichtigter Agent in einer Schleife kann das Kontingent schnell aufbrauchen. Überwachen Sie ihn daher anfangs einige Male, bevor Sie ihn einem cron-Job anvertrauen. Wenn Sie ein serverseitiges Modell wegen des Datenschutzes oder einer nicht kontingentierten Inferenz statt wegen der gehosteten Modelle von Google einsetzen möchten, handelt es sich um ein anderes Werkzeug. Das Self-Hosting eines offenen LLM mit Ollama auf einem VPS hält die Gewichte und Prompts auf Ihrem eigenen System. Dafür führen Sie ein deutlich kleineres Modell als Gemini aus.

Aktualisierung

Gemini CLI wird häufig veröffentlicht. Da Sie es in einem Präfix installiert haben, das Ihrem Benutzer gehört, benötigen Aktualisierungen niemals sudo:

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

Es gibt mehrere Release-Kanäle: @latest ist stabil, @preview ist die wöchentliche Vorschauversion und @nightly ist die neueste Entwicklungsversion. Fixieren Sie bei allem, worauf Sie angewiesen sind, die Version auf @latest. Bei nvm werden globale Pakete unter der aktiven Node-Version installiert. Nach nvm use zum Wechseln der Node-Version müssen Sie die CLI daher möglicherweise erneut installieren. Lesen Sie die Release Notes, statt jedem Patch nachzulaufen.

Fehlerbilder mit den exakten Zeichenfolgen

npm WARN EBADENGINE Unsupported engine ... required: { node: '>=20' } und anschließend ein Absturz der CLI zur Laufzeit. Node ist zu alt, die Distribution verwendet 18.19.1, und diese Version hat ebenfalls das Ende ihres Lebenszyklus überschritten. Installieren Sie Node 20+ über NodeSource oder nvm und bestätigen Sie die Version mit node --version. Wenn mehrere Node-Versionen installiert sind, prüfen Sie, ob which node auf die neue Version und nicht auf /usr/bin/node zeigt.

npm error code EACCES / permission denied, mkdir '/usr/lib/node_modules/...'. Die globale Installation erfolgt in ein Präfix, das root gehört. Verwenden Sie dafür nicht sudo. Setzen Sie npm config set prefix ~/.npm-global, nehmen Sie ~/.npm-global/bin in PATH auf und installieren Sie das Paket anschließend als normaler Benutzer neu. Wenn ein früheres sudo npm Cache-Dateien angelegt hat, die root gehören (Your cache folder contains root-owned files), 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, das Sie nicht erreichen können. Der OAuth-Ablauf benötigt einen Browser, den der Server nicht besitzt. Außerdem verweist der localhost-Callback auf den Server und nicht auf Ihren Laptop. Verwenden Sie den API-Key-Pfad (GEMINI_API_KEY), oder setzen Sie OAUTH_CALLBACK_PORT fest, leiten Sie ihn mit ssh -L über SSH weiter und öffnen Sie die URL lokal.

Der Prozess verschwand, als die SSH-Verbindung getrennt wurde. Sie haben gemini direkt in der SSH-Shell ausgeführt. Der Prozess war daher ein Kindprozess dieser Shell und wurde beim Trennen zusammen mit dem 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 Schlüssel weiterhin fehl, die CLI kehrt zu ihrer Auswahl für die Authentifizierung zurück oder eine Anfrage liefert API key not valid mit HTTP 400. Der Schlüssel ist in der Umgebung, die die CLI sieht, nicht vorhanden. Bestätigen Sie dies mit printenv GEMINI_API_KEY. Wenn die Ausgabe leer ist, wurde Ihre ~/.gemini_env nie eingelesen. Prüfen Sie, ob die Zeile in ~/.bashrc steht. Interaktive Shells, einschließlich tmux, lesen diese Datei ein, cron und andere nicht interaktive Shells jedoch nicht. Ein überflüssiges Leerzeichen oder Anführungszeichen im Schlüsselwert erzeugt ebenfalls API key not valid.

429 / RESOURCE_EXHAUSTED / eine Meldung zur Ratenbegrenzung. Sie haben das Kontingent der Authentifizierungsebene erreicht, die Ihre Authentifizierung verwendet. Warten Sie, bis das Zeitfenster zurückgesetzt wird, verlangsamen Sie den Agenten oder wechseln Sie zu einem kostenpflichtigen API-Key. Ein Agent, der in einer Wiederholungsschleife feststeckt, erreicht diese Begrenzung weiterhin. Stoppen Sie ihn und prüfen Sie, was er tut.

FAQ

Wie authentifiziere ich Gemini CLI auf einem Headless-Server?

Verwenden Sie einen API-Schlüssel, nicht die Browser-Anmeldung. Erstellen Sie einen Schlüssel in Google AI Studio, speichern Sie ihn in einer Datei mit Modus 600, die Ihre Shell einliest (export GEMINI_API_KEY=...), und die CLI überspringt den OAuth-Browserablauf vollständig. Wenn Sie ausdrücklich den kostenlosen Tarif für ein persönliches Konto verwenden möchten, fixieren Sie den Loopback-Port mit OAUTH_CALLBACK_PORT=8085, leiten Sie ihn mit ssh -L 8085:localhost:8085 user@server zu Ihrem Laptop weiter und öffnen Sie die ausgegebene URL lokal. Dafür müssen Sie jedoch an einem Browser anwesend sein. Für Skripte ist dieses Verfahren daher ungeeignet.

Warum verlangt die globale npm-Installation sudo, und wie kann ich das vermeiden?

Der Standardpräfix für globale npm-Pakete ist /usr/lib/node_modules. Ihr Benutzer kann dort nicht schreiben, daher schlägt ein einfaches npm install -g mit EACCES fehl. Die falsche Lösung ist sudo npm -g. Dadurch entstehen Dateien, die root gehören und spätere Installationen beeinträchtigen. Die richtige Lösung besteht darin, den Präfix auf Ihr Home-Verzeichnis zu setzen (npm config set prefix ~/.npm-global) und dessen bin zu PATH hinzuzufügen. Alternativ können Sie nvm verwenden. nvm installiert globale Pakete automatisch unter Ihrem Home-Verzeichnis.

Wie kann ich Gemini CLI nach dem Trennen der Verbindung weiter ausführen?

Führen Sie das Programm innerhalb von tmux aus. Ein Prozess, der aus Ihrer SSH-Shell gestartet wurde, endet beim Abbruch der Verbindung, weil er ein Kindprozess dieser Shell ist. tmux führt die Shell unter einem getrennten Server aus, der die Trennung übersteht. Verwenden Sie tmux new -A -s gemini, führen Sie darin gemini aus, trennen Sie die Sitzung mit Ctrl-b d und verbinden Sie sich später mit tmux attach -t gemini erneut.

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

Nur mit entsprechender Vorsicht. Ein Agent mit Shell-Zugriff kann alles ausführen, was der Benutzer ausführen darf, unter dem er läuft. Verwenden Sie einen dedizierten Benutzer ohne privilegierte Rechte und ohne sudo, halten Sie Zugangsdaten für die Produktion vom System fern, vermeiden Sie die automatische Genehmigung mit --yolo und verwenden Sie --sandbox (Docker oder Podman), um Tool-Aufrufe vom Host zu isolieren. Der Benutzer, unter dem der Agent läuft, ist wichtiger als jedes einzelne gesetzte Flag.

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

Nein. Gemini CLI ist ein Client, der ausgehende HTTPS-Verbindungen zu den APIs von Google herstellt. Es benötigt daher ausgehenden Port 443, aber keine eingehenden Ports. Wenn Sie den OAuth-Tunnel verwenden, liegt der fixierte Callback-Port, beispielsweise 8085, auf localhost und wird über Ihre SSH-Weiterleitung erreicht. Er ist kein geöffneter eingehender Port. Beschränken Sie eingehende Verbindungen weiterhin so weit wie möglich.