Gemini CLI na serwerze VPS: konfiguracja headless

Co budujesz

Zawsze uruchomiony interfejs CLI dla Gemini na własnym serwerze, dostępny przez SSH, wykonujący długotrwałe zadania agenta, które kontynuują pracę po zamknięciu laptopa. Instalacja składa się z trzech poleceń. Nakładu pracy wymaga wszystko, co zakłada środowisko graficzne: CLI Google próbuje otworzyć przeglądarkę w celu zalogowania, a serwer jej nie posiada. Dlatego większość tego przewodnika dotyczy pracy w trybie headless, instalacji aktualnej wersji Node, której nie dostarcza dystrybucja, globalnej instalacji npm niewymagającej uprawnień root, uwierzytelniania bez przeglądarki przy użyciu klucza API przechowywanego poza historią powłoki oraz użycia tmux, aby zerwane połączenie SSH nie przerywało działającego zadania.

Gemini CLI to program Node typu open-source (Apache-2.0) (@google/gemini-cli), który komunikuje się z modelami Gemini firmy Google i potrafi odczytywać oraz zapisywać pliki, wykonywać polecenia powłoki i obsługiwać narzędzia w katalogu roboczym. Na serwerze VPS jest to niewielki, zawsze dostępny agent, którego można pozostawić w trakcie pracy, dlatego konto, na którym działa, oraz poświadczenia znajdujące się na maszynie mają większe znaczenie niż jakiekolwiek pojedyncze ustawienie opisane w tym dokumencie.

Wymagania wstępne i istotne pułapki

• Świeży serwer VPS KVM z systemem Ubuntu 24.04 oraz dostępem root lub sudo. Każdy plan KVM jest wystarczający; sam interfejs CLI jest lekki i w spoczynku zajmuje kilkaset MB pamięci RAM.
• Node.js w wersji 20 lub nowszej. Jest to sztywne wymaganie minimalne, a pakiet dostępny w dystrybucji jest starszy – szczegóły znajdują się w kolejnej sekcji.
• Ruch wychodzący HTTPS (port 443) do API Google. Nie są wymagane żadne porty przychodzące; narzędzie działa jako klient, a nie serwer, więc nie ma potrzeby otwierania portów w zaporze sieciowej.
• Metoda uwierzytelniania niewymagająca przeglądarki na serwerze: klucz API Gemini z Google AI Studio lub tunel SSH do przeglądarki na komputerze lokalnym. Ścieżka z kluczem API jest skalowalna i zalecana dla skryptów oraz zadań uruchamianych bez nadzoru.
• Docker lub Podman, tylko jeśli wymagana jest izolacja --sandbox. Jest to opcjonalne i zostało opisane pod koniec dokumentacji.

Pułapka, na którą trafia większość użytkowników: przyjazny proces logowania gemini przy pierwszym uruchomieniu jest zaprojektowany dla środowisk graficznych. Próbuje on otworzyć przeglądarkę, co na serwerze bez interfejsu graficznego kończy się błędem lub wygenerowaniem niedziałającego linku. Należy wybrać metodę uwierzytelniania przed rozpoczęciem instalacji.

Uwaga: pakiet w dystrybucji jest zbyt stary

Ubuntu 24.04 dostarcza Node 18.19.1 w swoich repozytoriach, wraz z npm 9.2.0. Plik package.json narzędzia Gemini CLI deklaruje engines: { node: ">=20" }, a npm domyślnie nie przerywa instalacji w przypadku niezgodności; instaluje pakiet, wyświetlając ostrzeżenie wskazujące na różnicę:

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 }

Zignorowanie tego ostrzeżenia powoduje, że CLI działa w nieobsługiwanym środowisku uruchomieniowym, co prowadzi do błędów lub awarii w momencie wywołania API z Node 20+, którego CLI oczekuje. Node 18 osiągnął również koniec wsparcia (end-of-life) w kwietniu 2025, więc jest to rozwiązanie nieprzyszłościowe. Zainstaluj aktualną wersję LTS przed instalacją CLI. Dwie poprawne metody to NodeSource (podpisane repozytorium apt dla całego systemu) lub nvm (menedżer wersji dla użytkownika). Wybierz jedną z nich.

NodeSource, jeśli Node ma być dostępny dla każdego użytkownika w systemie:

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 musi zwrócić v20.x lub wyższą wersję, v24.x to aktualnie wspierana wersja LTS. Sprawdź stronę NodeSource, aby uzyskać bieżący skrypt instalacyjny; setup_24.x w adresie URL to parametr, który należy zmienić po wydaniu nowszej wersji LTS.

nvm, jeśli wolisz przechowywać Node w katalogu domowym użytkownika i nie używać sudo:

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

Wersja v0.40.1 w tym adresie URL była aktualna w momencie pisania tego tekstu; sprawdź plik README projektu nvm, aby poznać najnowsze wydanie i podmień wersję przed uruchomieniem skryptu. nvm ma istotną zaletę w tym przypadku: instaluje Node oraz pakiety globalne w ~/.nvm, dzięki czemu problem z uprawnieniami przy instalacji globalnej, opisany w następnej sekcji, w ogóle nie występuje. Jeśli wybierzesz metodę z nvm, możesz pominąć krok dotyczący npm-prefix.

Instalacja CLI bez sudo npm -g

Kuszącym poleceniem jest sudo npm install -g @google/gemini-cli. Nie należy go używać. Globalny prefiks należący do root powoduje błędy uprawnień przy każdej kolejnej instalacji i pozostawia w pamięci podręcznej npm pliki należące do root, co wywoła problemy w przyszłości. Uruchomienie zwykłego (bez sudo) npm install -g w systemowym Node prowadzi do innego błędu:

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'

Jest to próba zapisu przez npm do /usr/lib, do czego użytkownik nie posiada uprawnień. Rozwiązaniem nie jest sudo, lecz wskazanie globalnego prefiksu npm na katalog domowy, aby globalne instalacje trafiały do lokalizacji, do której użytkownik ma pełne prawa:

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

Użycie ~/.bashrc, a nie ~/.profile, jest celowe: tmux, w którym CLI będzie uruchamiane za dwie sekcje, inicjuje powłokę typu non-login, która odczytuje ~/.bashrc i pomija ~/.profile. W rezultacie linia PATH w niewłaściwym pliku sprawi, że gemini będzie niewidoczne dokładnie tam, gdzie jest wymagane. Wyświetlenie numeru wersji przez gemini --version stanowi pełny test. Jeśli zamiast tego pojawi się gemini: command not found, eksport PATH nie został zastosowany; należy sprawdzić tryby awarii. W przypadku nvm należy całkowicie pominąć linie z prefiksem: instaluje on pakiety globalne w katalogu domowym automatycznie.

Jeśli wcześniej uruchomiono sudo npm i widoczny jest błąd Your cache folder contains root-owned files, należy go jednorazowo naprawić za pomocą sudo chown -R $(id -u):$(id -g) ~/.npm.

Problem uwierzytelniania bez interfejsu graficznego i sposoby jego rozwiązania

Uruchomienie gemini w trybie interaktywnym po raz pierwszy powoduje wyświetlenie prośby o zalogowanie się za pomocą konta Google. Na komputerze stacjonarnym otwiera to kartę przeglądarki. Na serwerze VPS bez interfejsu graficznego przeglądarka nie istnieje, więc proces albo wyświetla adres URL localhost, który należy otworzyć, albo kończy się błędem typu:

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

Pułapką jest redirect_uri=http://localhost:PORT. Nawet jeśli otworzysz ten adres URL na swoim laptopie i zatwierdzisz logowanie, Google przekieruje Cię na http://localhost:PORT, czyli localhost na serwerze, do portu, do którego Twój laptop nie ma dostępu. Logowanie nigdy nie zostanie ukończone.

Istnieją dwa poprawne sposoby rozwiązania tego problemu.

Pierwszym jest użycie klucza API, co stanowi zalecane rozwiązanie dla serwera. Utwórz klucz w Google AI Studio (aistudio.google.com) i przekaż go do CLI jako zmienną środowiskową; narzędzie odczytuje GEMINI_API_KEY i całkowicie pomija proces logowania przez przeglądarkę. Należy pamiętać o zasadzie „nie przechowuj w historii ani w plikach dostępnych dla innych użytkowników”. Nie wpisuj export GEMINI_API_KEY=AIza... w wierszu poleceń, ponieważ trafi on do ~/.bash_history w postaci jawnej. Nie umieszczaj go również w pliku, który mogą odczytać inne osoby. Zapisz go w pliku z uprawnieniami 600, który powłoka wczytuje przy starcie:

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 oznacza, że tylko Twój użytkownik może odczytać ten plik. Potwierdź, że klucz został załadowany do środowiska za pomocą printenv GEMINI_API_KEY; jeśli polecenie nic nie wyświetli, CLI powróci do procesu logowania przez przeglądarkę i zakończy się błędem. Narzędzie odczytuje również plik .env w ~/.gemini/, jeśli preferujesz taką strukturę, przy zachowaniu tej samej zasady, czyli chmod 600 ~/.gemini/.env.

Drugi sposób pozwala zachować logowanie przez osobiste konto Google (i korzystanie z darmowego planu) poprzez tunelowanie wywołania zwrotnego OAuth do Twojego laptopa. Problemem jest to, że serwer pętli zwrotnej (loopback) CLI wiąże się z losowym portem przy każdym uruchomieniu, więc nie ma stałego portu do przekierowania, chyba że zostanie on wcześniej przypisany za pomocą zmiennej środowiskowej OAUTH_CALLBACK_PORT, a następnie przekierowany:

# 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 nie może otworzyć przeglądarki, więc wyświetla adres URL uwierzytelniania; otwórz go w przeglądarce na laptopie, zatwierdź, a gdy Google przekieruje na http://localhost:8085/..., przekierowanie SSH przeniesie żądanie do serwera pętli zwrotnej na VPS i logowanie zostanie ukończone. Jeśli pozostawisz port nieprzypisany, przy każdym uruchomieniu będzie on losowy, czego nie obsłuży żadne wcześniej skonfigurowane ssh -L. Metoda ta działa, ale wymaga obecności użytkownika przy przeglądarce, więc nie nadaje się do skryptów. W przypadku usług działających w tle należy użyć klucza API.

Dla Vertex AI lub projektu Google Cloud zamiast AI Studio, ustaw GOOGLE_API_KEY wraz z GOOGLE_GENAI_USE_VERTEXAI=true lub GOOGLE_CLOUD_PROJECT dla licencji Code Assist, stosując tę samą dyscyplinę zmiennych środowiskowych i plik z uprawnieniami 600.

Uruchomienie wewnątrz tmux, aby zerwane połączenie SSH nie przerywało procesu

Proces gemini uruchomiony bezpośrednio z powłoki SSH jest procesem potomnym tej powłoki. Utrata połączenia, zamknięcie laptopa, zerwanie Wi-Fi lub przekroczenie limitu czasu bezczynności powoduje, że sshd zamyka pseudo-terminal, powłoka otrzymuje sygnał SIGHUP i kończy działanie. Zadanie, które trwało dziesięć minut, zostaje przerwane, a po ponownym połączeniu nie ma możliwości odzyskania procesu.

tmux rozwiązuje ten problem, przejmując kontrolę nad powłoką zamiast sshd. Jest to ten sam schemat, co w przypadku uruchamiania agenta programistycznego AI na zdalnym VPS wewnątrz tmux, i działa tutaj identycznie:

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 podłącza się do sesji o nazwie gemini, jeśli istnieje, lub tworzy ją, jeśli nie – jest to zatem polecenie, które należy wykonać zaraz po każdym zalogowaniu. Powłoka wewnątrz należy do odłączonego serwera tmux, a nie do sesji SSH, więc zerwanie połączenia nie przerywa pracy CLI. Po ponownym połączeniu i podłączeniu do sesji, historia przewijania pozostaje dostępna. Jeśli na jednej maszynie uruchomionych jest kilka sesji agenta, po jednej na sesję tmux, nie mają one możliwości komunikacji między sobą, w przeciwieństwie do Claude Code, gdzie jedna sesja może przekazać tekst do drugiej na tym samym VPS. Należy zatem traktować każde zadanie Gemini jako niezależne lub koordynować je za pomocą plików na dysku.

W przypadku uruchomień skryptowych, nieinteraktywnych, Gemini CLI oferuje tryb bezgłowy (headless): gemini -p "summarise the failing tests in this repo" wypisuje odpowiedź i kończy działanie, a --output-format json generuje wyjście czytelne dla maszyny, które można przekierować dalej. Tryb bezgłowy z kluczem API jest rozwiązaniem zalecanym wewnątrz sesji tmux przy długotrwałych zadaniach wsadowych lub wywoływanych z cron. Należy pamiętać, że zadanie cron nie wczytuje plików konfiguracyjnych powłoki, dlatego należy w linii crontab zdefiniować własną zmienną GEMINI_API_KEY (lub wymusić wczytanie ~/.gemini_env), w przeciwnym razie CLI spróbuje uruchomić proces autoryzacji w przeglądarce i zakończy się błędem.

Izolacja i uprawnienia na serwerze produkcyjnym

Agent z dostępem do powłoki jest powłoką. Gemini CLI może wykonywać polecenia i domyślnie prosi o potwierdzenie każdego ryzykownego działania, jednak użytkownicy często sięgają po --yolo (automatyczne zatwierdzanie każdego wywołania narzędzia). W takim przypadku agent może usuwać pliki, wypychać zmiany do git lub łączyć się z usługami wewnętrznymi z pełnymi uprawnieniami użytkownika, na którym działa. Na serwerze obsługującym produkcję stanowi to realne zagrożenie, a nie hipotetyczny scenariusz.

Trzy mechanizmy kontroli, uszeregowane według skuteczności:

• Uruchamianie jako dedykowany użytkownik bez uprawnień. Nie root, nie członek grupy sudo. Należy utworzyć użytkownika agent z własnym katalogiem domowym, zainstalować tam Node oraz CLI. Dzięki temu błędnie zinterpretowane polecenie pozostanie ograniczone do tego konta. Jest to najważniejsza decyzja pod kątem bezpieczeństwa.
• Brak danych uwierzytelniających produkcję na serwerze. Żadnych kluczy ~/.aws/credentials produkcji, żadnych plików .env skopiowanych z produkcji, żadnych haseł do baz danych z uprawnieniami do zapisu w istotnych zasobach. Należy używać danych uwierzytelniających dla środowiska staging lub z dostępem tylko do odczytu.
• Korzystanie z wbudowanej piaskownicy. Przy zainstalowanym Docker lub Podman, gemini --sandbox (lub GEMINI_SANDBOX=docker) uruchamia wywołania narzędzi agenta wewnątrz kontenera odizolowanego od systemu plików hosta i sieci. Nie zastępuje to pracy na użytkowniku bez uprawnień, ale stanowi silną drugą warstwę ochrony, gdy ten sam VPS wykonuje realne zadania.

W przypadku uruchamiania Gemini CLI obok innych narzędzi self-hosted, na przykład serwera MCP udostępniającego narzędzia agentowi na tym samym VPS, każdą dodaną funkcjonalność należy traktować jako zwiększenie powierzchni ataku, do której agent ma dostęp. Tokeny przekazywane agentowi powinny być ograniczone do dokładnie jednego zadania.

Limit, koszt i wybór ścieżki uwierzytelniania

Ścieżka uwierzytelniania decyduje o sposobie naliczania opłat. Osobiste konto Google (ścieżka OAuth) korzysta z darmowego planu Gemini Code Assist, który posiada sztywne limity na minutę i na dzień; ich przekroczenie powoduje zwracanie błędu rate-limit do momentu zresetowania okna czasowego. Klucz API z AI Studio może działać w ramach planu darmowego lub płatnego, zależnie od projektu; klucz płatny zwiększa limity i nalicza opłaty za token. Uwierzytelnianie przez Vertex i projekt Google Cloud rozliczane jest poprzez Google Cloud.

Dwie praktyczne uwagi. Agent działający w pętli bez nadzoru może szybko wyczerpać limit, dlatego należy go monitorować podczas pierwszych uruchomień, zanim zostanie powierzony zadaniu cron. Jeśli powodem korzystania z modelu po stronie serwera jest prywatność lub nielimitowane wnioskowanie, a nie korzystanie z modeli hostowanych przez Google, należy użyć innego narzędzia. Samodzielne hostowanie otwartego modelu LLM za pomocą Ollama na VPS pozwala zachować wagi i prompty na własnej maszynie, kosztem uruchomienia znacznie mniejszego modelu niż Gemini.

Aktualizacja oprogramowania

Narzędzie Gemini CLI otrzymuje częste aktualizacje. Ponieważ instalacja została wykonana w prefiksie należącym do użytkownika, aktualizacje nie wymagają uprawnień sudo:

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

Dostępne są kanały wydań: @latest to wersja stabilna, @preview to cotygodniowa wersja zapoznawcza, @nightly to wersja rozwojowa; w przypadku systemów produkcyjnych należy przypiąć wersję do @latest. W środowisku nvm pakiety globalne znajdują się w katalogu aktywnej wersji Node, więc po wykonaniu nvm use w celu zmiany wersji Node może zaistnieć konieczność ponownej instalacji CLI. Zaleca się zapoznawanie z informacjami o wydaniu zamiast instalowania każdej poprawki.

Tryby awarii wraz z dokładnymi komunikatami

npm WARN EBADENGINE Unsupported engine ... required: { node: '>=20' }, a następnie awaria CLI w czasie wykonywania. Wersja Node jest zbyt stara, dystrybucja posiada 18.19.1, co oznacza również zakończenie wsparcia (end-of-life). Należy zainstalować Node 20+ z NodeSource lub nvm, potwierdzić wersję za pomocą node --version, a w przypadku posiadania kilku wersji Node, sprawdzić czy which node wskazuje na nową wersję, a nie na /usr/bin/node.

npm error code EACCES / permission denied, mkdir '/usr/lib/node_modules/...'. Instalacja globalna w prefiksie należącym do root. Nie należy używać sudo, należy ustawić npm config set prefix ~/.npm-global, dodać ~/.npm-global/bin do PATH i przeprowadzić reinstalację jako użytkownik bez uprawnień administratora. Jeśli wcześniejsza instalacja sudo npm pozostawiła pliki pamięci podręcznej należące do root (Your cache folder contains root-owned files), należy wykonać sudo chown -R $(id -u):$(id -g) ~/.npm.

Failed to open browser, zawieszające się logowanie lub redirect_uri=http://localhost:PORT, którego nie można osiągnąć. Proces OAuth wymaga przeglądarki, której serwer nie posiada, a jego callback localhost wskazuje na serwer, a nie na laptopa użytkownika. Należy użyć ścieżki z kluczem API (GEMINI_API_KEY) lub przypiąć OAUTH_CALLBACK_PORT, przekierować go przez SSH za pomocą ssh -L i otworzyć adres URL lokalnie.

Proces zniknął po zerwaniu połączenia SSH. Polecenie gemini zostało uruchomione bezpośrednio z powłoki SSH, więc było procesem potomnym tej powłoki i zakończyło się wraz z zamknięciem pty przy rozłączeniu. Brak możliwości odzyskania. Każdą sesję należy rozpoczynać od tmux new -A -s gemini i uruchamiać w niej CLI.

Uwierzytelnianie nadal kończy się niepowodzeniem mimo ustawionego klucza, CLI wraca do wyboru metody uwierzytelniania lub żądanie zwraca API key not valid z kodem HTTP 400. Klucz nie znajduje się w środowisku widocznym dla CLI. Należy potwierdzić to za pomocą printenv GEMINI_API_KEY; jeśli zmienna jest pusta, plik ~/.gemini_env nie został wczytany. Należy sprawdzić, czy odpowiednia linia znajduje się w ~/.bashrc, który jest odczytywany przez powłoki interaktywne (w tym tmux), ale nie przez cron i inne powłoki nieinteraktywne. Zbędna spacja lub cudzysłów wewnątrz wartości klucza również powoduje API key not valid.

429 / RESOURCE_EXHAUSTED / komunikat o przekroczeniu limitu zapytań (rate-limit). Osiągnięto limit dla poziomu uwierzytelniania, z którego korzysta użytkownik. Należy poczekać na zresetowanie okna czasowego, zmniejszyć częstotliwość zapytań agenta lub przejść na płatny klucz API. Agent zablokowany w pętli ponownych prób stale wyczerpuje limit; należy go zatrzymać i sprawdzić przyczynę działania.

FAQ

Jak uwierzytelnić Gemini CLI na serwerze bez monitora?

Należy użyć klucza API, a nie logowania przez przeglądarkę. Klucz tworzy się w Google AI Studio, a następnie umieszcza w pliku z uprawnieniami 600, z którego korzysta powłoka (export GEMINI_API_KEY=...). Dzięki temu CLI całkowicie pomija proces OAuth w przeglądarce. Jeśli wymagane jest korzystanie z darmowego planu dla kont osobistych, należy przypiąć port zwrotny za pomocą OAUTH_CALLBACK_PORT=8085, przekierować go na laptopa przy użyciu ssh -L 8085:localhost:8085 user@server i otworzyć wyświetlony adres URL lokalnie. Wymaga to jednak obecności użytkownika przy przeglądarce, więc rozwiązanie to nie nadaje się do skryptów.

Dlaczego instalacja globalna npm wymaga sudo i jak tego uniknąć?

Domyślny prefiks globalny npm to /usr/lib/node_modules, do którego użytkownik nie ma uprawnień zapisu, dlatego zwykłe polecenie npm install -g kończy się błędem EACCES. Błędnym rozwiązaniem jest użycie sudo npm -g, co prowadzi do powstania plików należących do roota, które uniemożliwiają późniejsze instalacje. Prawidłowym rozwiązaniem jest wskazanie prefiksu w katalogu domowym (npm config set prefix ~/.npm-global) i dodanie jego ścieżki bin do PATH lub użycie nvm, który automatycznie instaluje pakiety globalne w katalogu domowym.

Jak utrzymać działanie Gemini CLI po rozłączeniu sesji?

Należy uruchomić narzędzie wewnątrz tmux. Proces uruchomiony z powłoki SSH kończy się po zerwaniu połączenia, ponieważ jest procesem potomnym tej powłoki. tmux uruchamia powłokę w ramach odłączonego serwera, który przetrwa rozłączenie. Należy użyć tmux new -A -s gemini, uruchomić gemini, odłączyć się za pomocą Ctrl-b d i powrócić do sesji później komendą tmux attach -t gemini.

Czy uruchamianie Gemini CLI na serwerze produkcyjnym jest bezpieczne?

Tylko przy zachowaniu ostrożności, ponieważ agent z dostępem do powłoki może wykonać dowolne operacje w ramach uprawnień użytkownika, na którym działa. Narzędzie należy uruchamiać jako dedykowany użytkownik bez uprawnień sudo, nie przechowywać na maszynie danych uwierzytelniających środowisko produkcyjne, unikać automatycznego zatwierdzania --yolo oraz stosować --sandbox (Docker lub Podman) w celu odizolowania wywołań narzędzi od hosta. Konto, na którym działa proces, ma większe znaczenie niż jakakolwiek pojedyncza flaga.

Czy muszę otwierać porty w zaporze sieciowej dla Gemini CLI?

Nie. Jest to klient wykonujący wychodzące połączenia HTTPS do API Google, więc wymaga jedynie otwartego portu 443 dla ruchu wychodzącego i żadnych portów przychodzących. W przypadku korzystania z tunelu OAuth, przypięty port zwrotny (na przykład 8085) działa na localhost i jest dostępny przez przekierowanie SSH, a nie przez otwarty port przychodzący. Ruch przychodzący powinien pozostać zablokowany.