Headless VPS uzerinde Gemini CLI kurulumu

Ne inşa ediyorsunuz

Kendi sunucunuzda çalışan, SSH üzerinden erişilebilen ve dizüstü bilgisayarınızı kapattıktan sonra bile uzun süreli görevleri yürütmeye devam eden, her zaman açık bir Gemini CLI. Kurulum üç komuttan oluşur. Masaüstü ortamı varsayan her şey ekstra çaba gerektirir: Google'ın CLI aracı giriş yapmak için bir tarayıcı açmak ister, ancak sunucunuzda tarayıcı yoktur. Bu nedenle rehberin büyük kısmı başsız (headless) kurulum yolunu, dağıtımınızın sağlamadığı güncel bir Node sürümünü, root yetkisi gerektirmeyen global bir npm kurulumunu, shell geçmişinizde tutmayacağınız bir API anahtarı ile tarayıcısız kimlik doğrulamasını ve kesilen SSH oturumlarının çalışan görevi sonlandırmaması için tmux kullanımını kapsar.

Gemini CLI, Google'ın Gemini modelleriyle iletişim kuran, dosya okuyup yazabilen, shell komutları çalıştırabilen ve çalışma dizinindeki araçları yönetebilen açık kaynaklı (Apache-2.0) bir Node programıdır (@google/gemini-cli). Bir VPS üzerinde bu araç, çalışmaya bırakabileceğiniz küçük ve her zaman erişilebilir bir ajandır; bu nedenle, aracın hangi kullanıcı hesabıyla çalıştığı ve sunucuda tutulan kimlik bilgileri, buradaki herhangi bir ayardan çok daha önemlidir.

Ön gereksinimler ve dikkat edilmesi gereken noktalar

• root veya sudo yetkilerine sahip, yeni kurulmuş bir Ubuntu 24.04 KVM VPS. Herhangi bir KVM planı yeterlidir; CLI oldukça hafiftir, boşta çalışırken birkaç yüz MB RAM tüketir.
• Node.js 20 veya daha yeni bir sürüm. Bu kesin bir alt sürüm sınırıdır ve dağıtım paketleri bu sürümün altındadır, sonraki bölüme bakınız.
• Google API'lerine giden HTTPS (443 numaralı port) trafiği. Gelen portlara ihtiyaç yoktur; bu bir sunucu değil istemcidir, bu nedenle güvenlik duvarında herhangi bir port açmanız gerekmez.
• Sunucu üzerinde tarayıcı gerektirmeyen bir kimlik doğrulama yöntemi: Google AI Studio üzerinden alınacak bir Gemini API anahtarı veya kendi makinenizdeki bir tarayıcıya yönlendirilen bir SSH tüneli. API anahtarı yöntemi, betikler ve katılımsız çalıştırmalar için ölçeklenebilir olan yoldur.
• Yalnızca --sandbox izolasyonu istiyorsanız Docker veya Podman. İsteğe bağlıdır, son bölümlerde ele alınmıştır.

Herkesi yanıltan nokta şudur: Kullanıcı dostu gemini ilk çalıştırma giriş akışı masaüstü ortamları için tasarlanmıştır. Bir tarayıcı açmaya çalışır ve başsız (headless) bir sunucuda ya hata verir ya da çalışmayan bir bağlantı sunar. Başlamadan önce kimlik doğrulama yoluna karar verin.

Not: dağıtım paketi çok eski

Ubuntu 24.04, kendi depolarında Node 18.19.1 sürümünü ve bununla eşleşen npm 9.2.0 sürümünü sunar. Gemini CLI'ın package.json dosyası engines: { node: ">=20" } gereksinimini belirtir; npm varsayılan olarak bir uyumsuzluk durumunda işlemi durdurmaz, kurulumu yapar ve aradaki farkı belirten bir uyarı yazdırır:

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 }

Bu uyarıyı göz ardı edip devam ederseniz CLI desteklenmeyen bir çalışma zamanında çalışır. CLI, var olduğunu varsaydığı bir Node 20+ API'sine ulaştığı anda hatalı davranır veya çöker. Node 18 ayrıca Nisan 2025 itibarıyla ömrünü tamamlamıştır (end-of-life), dolayısıyla her iki durumda da çıkmaz bir yoldur. CLI'ı kurmadan önce güncel bir LTS sürümü kurun. İki temiz yöntem mevcuttur: NodeSource (sistem genelinde imzalı bir apt deposu) veya nvm (kullanıcı bazlı bir sürüm yöneticisi). Birini seçin.

Sunucudaki her kullanıcının Node'a erişmesini istiyorsanız NodeSource yöntemini kullanın:

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 komutu v20.x veya daha yüksek bir sürüm çıktısı vermelidir; v24.x şu anki aktif LTS sürümüdür. Güncel kurulum betiği için NodeSource sayfasını kontrol edin; URL içindeki setup_24.x ifadesi, yeni bir LTS sürümü yayınlandığında güncellenmesi gereken kısımdır.

Node'u yalnızca bir kullanıcının ev dizininde tutmak ve sudo ile hiçbir şekilde müdahale etmemek istiyorsanız nvm yöntemini kullanın:

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

Bu URL'deki v0.40.1 ifadesi yazıldığı tarihte günceldi; en son sürüm için nvm'in README dosyasını kontrol edin ve komutu çalıştırmadan önce sürüm numarasını güncelleyin. nvm'in bu iş için gerçek bir avantajı vardır: Node'u ve global paketlerini ~/.nvm dizini altına kurar, böylece bir sonraki bölümde bahsedilen global kurulum izin sorunları hiçbir şekilde yaşanmaz. nvm yolunu seçerseniz npm-prefix adımını atlayabilirsiniz.

CLI'yi sudo npm -g olmadan kurmak

Cazip görünen komut sudo npm install -g @google/gemini-cli şeklindedir. Bunu yapmayın. root sahipliğinde bir global önek, sonraki her kurulumda izin hatalarına yol açar ve npm önbelleğinizde aylar sonra sorun çıkaracak root sahipliğinde dosyalar bırakır. Sistem Node'u üzerinde sudo kullanmadan düz bir npm install -g çalıştırırsanız diğer hata ile karşılaşırsınız:

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'

Bu, npm'in kullanıcınızın yazma yetkisi olmayan /usr/lib dizinine yazmaya çalışmasıdır. Çözüm sudo kullanmak değil, npm'in global önekini ev dizininize yönlendirerek global kurulumların sahip olduğunuz bir yere yapılmasını sağlamaktır:

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

~/.profile yerine ~/.bashrc kullanımı kasıtlıdır: CLI'yi iki bölüm sonra içinde çalıştıracağınız tmux, ~/.bashrc dosyasını okuyan ancak ~/.profile dosyasını atlayan bir login olmayan kabuk başlatır; bu nedenle yanlış dosyadaki bir PATH satırı, gemini değişkenini tam da ihtiyaç duyduğunuz yerde görünmez kılar. gemini --version komutunun bir sürüm numarası yazdırması tüm testin kendisidir. Bunun yerine gemini: command not found alıyorsanız, PATH dışa aktarma işleminiz gerçekleşmemiştir; hata modlarına bakın. nvm kullanıyorsanız, önek satırlarını tamamen atlayın: nvm, global paketleri zaten ev dizininizin altına kurar.

Daha önce sudo npm çalıştırdıysanız ve şimdi Your cache folder contains root-owned files görüyorsanız, bunu sudo chown -R $(id -u):$(id -g) ~/.npm ile bir defaya mahsus onarın.

The headless auth problem, and how to get past it

Run gemini interactively the first time and it offers to log you in with your Google account. On a desktop that opens a browser tab. On a headless VPS there is no browser, so the flow either prints a localhost URL it expects you to open, or fails outright with something like:

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

The trap is the redirect_uri=http://localhost:PORT. Even if you open that URL on your laptop and approve it, Google redirects to http://localhost:PORT, localhost on the server, a port nothing on your laptop can reach. The login never completes.

There are two honest ways through.

The first is an API key, and it is the right default for a server. Create a key in Google AI Studio (aistudio.google.com) and hand it to the CLI as an environment variable; it reads GEMINI_API_KEY and skips the browser flow entirely. Now the "keep it out of history and world-readable files" part. Do not type export GEMINI_API_KEY=AIza... at the prompt, it lands in ~/.bash_history in cleartext, and do not put it in a file others can read. Write it to a mode-600 file the shell sources at start:

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 means only your user can read the file. Confirm the key reached the environment with printenv GEMINI_API_KEY; if that prints nothing, the CLI falls back to the browser flow and fails. It also reads a .env file in ~/.gemini/ if you prefer that layout, same rule, so chmod 600 ~/.gemini/.env.

The second way keeps the personal-Google-account login (and its free tier) by tunnelling the OAuth callback back to your laptop. The catch is that the CLI's loopback server binds a random port each run, so there is nothing stable to forward unless you pin it first with the OAUTH_CALLBACK_PORT environment variable, then forward exactly that 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

The CLI cannot open a browser, so it prints the auth URL; open it in your laptop browser, approve, and when Google redirects to http://localhost:8085/... the SSH forward carries it to the loopback server on the VPS and the login completes. Leave the port unpinned and it lands on a fresh random port every run, which no ssh -L set up in advance can catch. It works, but it needs you sitting at a browser, so it is no good for scripts. For anything you leave running, use the API key.

For Vertex AI or a Google Cloud project instead of AI Studio, set GOOGLE_API_KEY together with GOOGLE_GENAI_USE_VERTEXAI=true, or GOOGLE_CLOUD_PROJECT for a Code Assist licence, same environment-variable discipline, same mode-600 file.

SSH oturumu koptuğunda işlemin sonlanmaması için tmux içinde çalıştırın

Doğrudan SSH kabuğunuzdan başlattığınız bir gemini süreci, o kabuğun bir alt sürecidir. Bağlantının kopması, dizüstü bilgisayarın kapanması, Wi-Fi kesintisi veya boşta kalma zaman aşımı gibi durumlarda sshd sözde terminali (pseudo-terminal) sonlandırır, kabuk SIGHUP sinyali alır ve CLI üzerindeki süreç de kapanır. Dosya düzenleme işleminin onuncu dakikasında süreç ölür ve yeniden bağlandığınızda kurtarabileceğiniz bir süreç kalmaz.

tmux, kabuğun sahipliğini sshd yerine kendi üzerine alarak bu sorunu çözer. Bu, uzak bir VPS üzerinde tmux içinde yapay zeka kodlama aracı çalıştırmak ile aynı yöntemdir ve burada da birebir aynı şekilde çalışır:

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, eğer mevcutsa gemini isimli oturuma bağlanır, yoksa bu oturumu oluşturur; bu nedenle her girişten sonra çalıştırılması gereken tek komut budur. İçerideki kabuk SSH oturumunuza değil, arka planda çalışan tmux sunucusuna aittir; bu yüzden bağlantı kopsa bile CLI çalışmaya devam eder. Yeniden bağlandığınızda oturuma tekrar dahil olur ve kaldığınız yerden devam edersiniz. Eğer tek bir sunucuda her biri farklı bir tmux oturumunda olmak üzere birden fazla araç oturumu çalıştırırsanız, Claude Code'un aksine aynı VPS üzerinde bir oturumun diğerine metin aktarabildiği bir yapı burada mevcut değildir; bu yüzden her Gemini işini bağımsız tutun veya bunları disk üzerindeki dosyalar aracılığıyla koordine edin.

Etkileşimli olmayan, betik tabanlı çalıştırmalar için Gemini CLI'ın başsız (headless) modu mevcuttur: gemini -p "summarise the failing tests in this repo" bir yanıt yazdırıp çıkar, --output-format json ise başka bir yere yönlendirilebilecek makine tarafından okunabilir bir çıktı verir. API anahtarı ile kullanılan başsız mod, uzun süreli bir toplu iş çalıştıran tmux oturumunda veya bir cron girdisinden tetiklendiğinde tam olarak ihtiyaç duyduğunuz şeydir. Ancak bir uyarı: cron işleri giriş dosyalarınızı (login files) kaynaklamaz (source etmez), bu yüzden crontab satırına kendi GEMINI_API_KEY değerinizi verin (veya komutun ~/.gemini_env dosyasını kaynaklamasını sağlayın); aksi takdirde CLI tarayıcı tabanlı kimlik doğrulama akışına düşer ve başarısız olur.

Üretim ortamının da çalıştığı bir sunucuda korumalı alan (sandboxing) ve izinler

Kabuk erişimine sahip bir aracı, bir kabuktur. Gemini CLI komutları çalıştırabilir ve varsayılan olarak her riskli komuttan önce onay ister; ancak kullanıcılar --yolo (her araç çağrısını otomatik onayla) seçeneğine yöneldiğinde, aracı dosyaları silebilir, git deposuna gönderim yapabilir veya çalıştığı kullanıcının tüm yetkileriyle dahili servislere erişebilir. Üretim ortamının da çalıştığı bir sunucuda bu durum varsayımsal değil, gerçek bir etki alanıdır.

Size sağladıkları fayda sırasına göre üç kontrol mekanizması:

• Özel ve yetkisiz bir kullanıcı olarak çalıştırın. root kullanıcısı veya sudo üyesi olmamalıdır. Kendi ev dizinine sahip bir agent kullanıcısı oluşturun, Node ve CLI'ı buraya kurun; böylece yanlış anlaşılan bir komut sadece o hesapla sınırlı kalır. Bu, atılabilecek en değerli adımdır.
• Üretim ortamı kimlik bilgilerini sunucuda tutmayın. Üretim ortamına ait ~/.aws/credentials, üretimden kopyalanmış .env veya önemli herhangi bir yere yazma erişimi olan veritabanı parolası bulundurmayın. Araca sadece test (staging) veya salt okunur yetkiye sahip kimlik bilgileri verin.
• Yerleşik korumalı alanı (sandbox) kullanın. Docker veya Podman yüklüyken, gemini --sandbox (veya GEMINI_SANDBOX=docker) aracın araç çağrılarını, ana bilgisayar dosya sisteminden ve ağdan yalıtılmış bir container içinde çalıştırır. Bu, yetkisiz kullanıcı kullanımının yerini tutmaz ancak aynı VPS üzerinde gerçek işler yürütülürken güçlü bir ikinci katman sağlar.

Gemini CLI'ı diğer self-hosted araçlarla birlikte çalıştırıyorsanız, örneğin aynı VPS üzerinde araca araçlar sunan bir MCP sunucusu kullanıyorsanız, eklenen her yeteneği aracın ulaşabileceği daha geniş bir yüzey olarak değerlendirin ve araca verilen token'ları tam olarak tek bir görevle sınırlandırın.

Kota, maliyet ve seçilen kimlik doğrulama yolu

Kimlik doğrulama yolu, faturalandırma biçiminizi belirler. Kişisel bir Google hesabı (OAuth yolu), dakika ve gün bazında katı limitleri olan ücretsiz Gemini Code Assist katmanını kullanır; bu limitler aşıldığında, süre sıfırlanana kadar istekler hız sınırı hatası döndürür. AI Studio üzerinden alınan bir API anahtarı, projeye bağlı olarak ücretsiz katmanda olabilir veya faturalandırılabilir; faturalandırılan bir anahtar limitleri yükseltir ve token başına ücretlendirme yapar. Vertex ve Cloud projesi kimlik doğrulaması ise Google Cloud üzerinden faturalandırılır.

İki pratik not: Döngü içindeki denetimsiz bir aracı, kotayı hızla tüketebilir; bu nedenle bir cron job görevine emanet etmeden önce ilk birkaç seferde aracı izleyin. Eğer sunucu taraflı bir model kullanma nedeniniz Google'ın barındırdığı modeller yerine gizlilik veya sınırsız çıkarım yapmaksa, bu farklı bir konudur; Ollama ile bir VPS üzerinde açık kaynaklı LLM barındırmak, Gemini'dan çok daha küçük bir model çalıştırma maliyetiyle ağırlıkları ve istemleri kendi sunucunuzda tutmanızı sağlar.

Güncel tutma

Gemini CLI sık sık yeni sürümler yayınlar. Kullanıcıya ait bir dizine kurulum yaptığınız için güncellemeler hiçbir zaman sudo gerektirmez:

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

Yayın kanalları mevcuttur: @latest kararlı sürümdür, @preview haftalık önizleme sürümüdür, @nightly ise en güncel ancak test edilmemiş sürümdür; güvendiğiniz sistemlerde @latest sürümünü sabitleyin. nvm kullanıldığında, global paketler aktif Node sürümü altında barındırılır; bu nedenle Node sürümünü değiştirmek için nvm use komutunu kullandıktan sonra CLI'ı yeniden yüklemeniz gerekebilir. Her yamayı takip etmek yerine sürüm notlarını okuyun.

Hata modları ve kesin dizeler

npm WARN EBADENGINE Unsupported engine ... required: { node: '>=20' } ve ardından çalışma zamanında CLI çökmesi. Node sürümü çok eskidir; dağıtımın sunduğu 18.19.1 sürümü ömrünü tamamlamıştır. NodeSource veya nvm üzerinden Node 20+ sürümünü kurun, node --version ile doğrulayın. Eğer sistemde birden fazla Node sürümü yüklüyse, which node değerinin /usr/bin/node yerine yeni sürüme işaret ettiğinden emin olun.

npm error code EACCES / permission denied, mkdir '/usr/lib/node_modules/...'. root sahipliğindeki bir dizine global kurulum yapılmıştır. sudo kullanmayın, npm config set prefix ~/.npm-global değerini ayarlayın, ~/.npm-global/bin dizinini PATH içine ekleyin ve normal kullanıcı yetkileriyle yeniden kurun. Eğer önceki bir sudo npm işlemi root sahipliğinde önbellek dosyaları (Your cache folder contains root-owned files) bıraktıysa, sudo chown -R $(id -u):$(id -g) ~/.npm komutunu çalıştırın.

Failed to open browser, yanıt vermeyen bir oturum açma işlemi veya erişilemeyen bir redirect_uri=http://localhost:PORT. OAuth akışı, sunucuda bulunmayan bir tarayıcıya ihtiyaç duyar ve localhost geri çağırma adresi dizüstü bilgisayarınız yerine sunucuya yönlenir. API anahtarı yolunu (GEMINI_API_KEY) kullanın veya OAUTH_CALLBACK_PORT değerini sabitleyip ssh -L ile SSH üzerinden yönlendirin ve URL'yi yerel makinenizde açın.

SSH bağlantısı kesildiğinde sürecin kaybolması. gemini komutunu doğrudan SSH kabuğu üzerinden çalıştırdınız; bu nedenle süreç, kabuğun bir alt öğesi oldu ve bağlantı kesildiğinde pty ile birlikte sonlandı. Kurtarılacak bir veri yoktur. Her oturumu tmux new -A -s gemini ile başlatın ve CLI'ı bu oturum içinde çalıştırın.

Anahtar ayarlı olmasına rağmen kimlik doğrulamanın başarısız olması, CLI'ın tekrar kimlik doğrulama seçimine dönmesi veya bir isteğin HTTP 400 koduyla API key not valid döndürmesi. Anahtar, CLI'ın gördüğü ortam değişkenlerinde tanımlı değildir. printenv GEMINI_API_KEY ile kontrol edin; eğer boşsa ~/.gemini_env dosyanız hiçbir zaman kaynaklanmamıştır (sourced). Satırın, etkileşimli kabukların (tmux dahil) okuduğu ancak cron gibi etkileşimli olmayan kabukların okumadığı ~/.bashrc dosyasında bulunduğunu doğrulayın. Anahtar değeri içindeki fazladan bir boşluk veya tırnak işareti de API key not valid hatasına yol açar.

429 / RESOURCE_EXHAUSTED / hız sınırı (rate-limit) mesajı. Kimlik doğrulamanızın bağlı olduğu katmanın kotasını doldurdunuz. Pencerenin sıfırlanmasını bekleyin, aracın hızını düşürün veya ücretli bir API anahtarına geçin. Yeniden deneme döngüsünde takılı kalan bir araç bu hatayı tetiklemeye devam eder; aracı durdurun ve ne yaptığını inceleyin.

FAQ

Gemini CLI kimlik doğrulaması başsız (headless) bir sunucuda nasıl yapılır?

Tarayıcı girişi yerine bir API anahtarı kullanın. Google AI Studio üzerinden bir anahtar oluşturun, bu anahtarı shell'inizin okuduğu 600 modlu bir dosyaya (export GEMINI_API_KEY=...) kaydedin; böylece CLI, OAuth tarayıcı akışını tamamen atlayacaktır. Eğer özellikle kişisel hesap ücretsiz katmanını kullanmak istiyorsanız, loopback portunu OAUTH_CALLBACK_PORT=8085 ile sabitleyin, bunu ssh -L 8085:localhost:8085 user@server ile dizüstü bilgisayarınıza yönlendirin ve ekrana gelen URL'yi yerel tarayıcınızda açın. Ancak bu yöntem fiziksel olarak bir tarayıcı başında bulunmanızı gerektirdiğinden, betikler (scripts) için uygun değildir.

npm global kurulum neden sudo istiyor ve bunu nasıl önleyebilirim?

Çünkü npm'in varsayılan global öneki /usr/lib/node_modules dizinidir ve kullanıcınızın buraya yazma yetkisi yoktur; bu nedenle düz bir npm install -g komutu EACCES hatasıyla başarısız olur. Yanlış çözüm sudo npm -g kullanmaktır; bu, daha sonraki kurulumları bozacak root sahipli dosyalar bırakır. Doğru çözüm, öneki ev dizininize (npm config set prefix ~/.npm-global) yönlendirmek ve bunun bin dizinini PATH değişkenine eklemektir ya da global paketleri otomatik olarak ev dizininiz altına kuran nvm aracını kullanmaktır.

Bağlantımı kestiğimde Gemini CLI'ın çalışmaya devam etmesini nasıl sağlarım?

İşlemi tmux içinde çalıştırın. SSH shell'inizden başlatılan bir süreç, bağlantı koptuğunda sonlanır çünkü bu süreç shell'in bir alt öğesidir; tmux ise shell'i bağlantı kesilse bile hayatta kalan bağımsız bir sunucu altında çalıştırır. tmux new -A -s gemini komutunu kullanın, içinde gemini çalıştırın, Ctrl-b d ile oturumu ayırın ve daha sonra tmux attach -t gemini ile tekrar bağlanın.

Gemini CLI'ı üretim (production) sunucusunda çalıştırmak güvenli midir?

Yalnızca dikkatli bir şekilde güvenlidir, çünkü shell erişimi olan bir aracı, çalıştırıldığı kullanıcının yapabildiği her şeyi yapabilir. CLI'ı sudo yetkisi olmayan, özel ve kısıtlı bir kullanıcı altında çalıştırın, üretim kimlik bilgilerini makinede tutmayın, --yolo otomatik onay özelliğinden kaçının ve araç çağrılarını ana makineden izole etmek için --sandbox (Docker veya Podman) kullanın. CLI'ın hangi kullanıcı hesabı altında çalıştığı, ayarladığınız herhangi bir bayraktan (flag) çok daha önemlidir.

Gemini CLI için herhangi bir güvenlik duvarı portu açmam gerekiyor mu?

Hayır. Google API'lerine giden HTTPS çağrılarını yapan bir istemci olduğu için 443 numaralı giden portuna ihtiyaç duyar ancak gelen (inbound) portlara ihtiyaç duymaz. OAuth tünelini kullanırsanız, sabitlenen geri çağırma portu (örneğin 8085) localhost üzerinde çalışır ve açık bir gelen port üzerinden değil, SSH yönlendirmeniz üzerinden erişilir. Gelen trafiği kapalı tutmaya devam edin.