Headless VPS üzerinde Gemini CLI kurulumu

Ne inşa ediliyor

SSH üzerinden erişilebilen, dizüstü bilgisayar kapatıldıktan sonra bile çalışmaya devam eden uzun ajan görevlerini yürüten, sunucunuzda sürekli aktif bir Gemini CLI. Kurulum üç komuttan oluşur. Zorluk çıkaran kısım, masaüstü ortamı gerektiren işlemlerdir: Google'ın CLI aracı, oturum açmak için bir tarayıcı açmak ister ancak sunucunuzda tarayıcı bulunmaz. Bu nedenle rehberin büyük bölümü headless (arayüzsüz) yöntem üzerinedir: dağıtımın sağlamadığı güncel bir Node sürümü, root yetkisi gerektirmeyen global bir npm kurulumu, kabuk geçmişinde (shell history) tutulmayan bir API anahtarı ile tarayıcısız kimlik doğrulama ve SSH bağlantısı koptuğunda çalışan görevin durmaması için tmux kullanımı.

Gemini CLI, Google'ın Gemini modelleriyle iletişim kuran, dosya okuyup yazabilen, kabuk 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, çalışmaya bırakabileceğiniz küçük ve sürekli erişilebilir bir ajandır; bu nedenle programın çalıştığı kullanıcı hesabı ve sunucudaki kimlik bilgileri, buradaki herhangi bir ayardan daha kritiktir.

Ön Koşullar ve dikkat edilmesi gereken noktalar

• root veya sudo yetkisine sahip, yeni kurulmuş bir Ubuntu 24.04 KVM VPS. Herhangi bir KVM planı uygundur; CLI aracı oldukça hafiftir ve boşta çalışırken sadece birkaç yüz MB RAM tüketir.
• Node.js 20 veya daha yeni bir sürüm. Bu, kesin sürüm alt sınırıdır; dağıtım paketindeki sürüm ise bunun altındadır — bir sonraki bölüme bakınız.
• Google API'lerine doğru giden HTTPS (port 443) erişimi. Gelen bağlantı portuna ihtiyaç yoktur; bu bir sunucu değil, istemcidir, bu nedenle güvenlik duvarında herhangi bir port açılması gerekmez.
• Sunucu üzerinde tarayıcı gerektirmeyen bir kimlik doğrulama yöntemi: Google AI Studio'dan alınan bir Gemini API key veya kendi makinenizdeki tarayıcıya geri dönen bir SSH tüneli. API-key yöntemi, scriptler ve unattended (otomatik) çalıştırmalar için uygundur.
• Sadece --sandbox izolasyonu isteniyorsa Docker veya Podman. İsteğe bağlıdır, bölüm sonunda ele alınacaktır.

Herkesin karşılaştığı sorun: Kullanıcı dostu gemini ilk çalıştırma giriş akışı, masaüstü kullanımı için tasarlanmıştır. Bir tarayıcı açmaya çalışır; headless (arayüzsüz) bir sistemde ise ya hata verir ya da çalışmayan bir bağlantı sunar. Başlamadan önce kimlik doğrulama yöntemine karar veriniz.

Node: distro paketi çok eski

Ubuntu 24.04, kendi depolarında npm 9.2.0 ile birlikte Node 18.19.1 sürümünü sunar. Gemini CLI'ın package.json bileşeni engines: { node: ">=20" } sürümünü gerektirir. npm, varsayılan olarak sürüm uyumsuzluğunu engellemez; kurulumu gerçekleştirir ve aradaki farkı belirten bir uyarı mesajı 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ı geçseniz dahi CLI, desteklenmeyen bir çalışma ortamında çalışır. CLI, Node 20+ sürümlerinde bulunan bir API'ye ihtiyaç duyduğunda hatalı çalışır veya çöker. Node 18 sürümü Nisan 2025 itibarıyla kullanım ömrünü (end-of-life) tamamlamıştır, bu nedenle her iki durumda da geçersizdir. CLI kurulumundan önce güncel bir LTS sürümü kurun. İki temiz yöntem bulunmaktadır: NodeSource (sistem genelinde imzalı bir apt deposu) veya nvm (kullanıcı bazlı bir sürüm yöneticisi). Birini seçin.

Sistemdeki tüm kullanıcılar için Node erişimi istiyorsanız NodeSource:

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 sürümü v20.x veya daha yüksek bir sürüm yazdırmalıdır; v24.x güncel 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 kısmı, yeni bir LTS çıktığında güncellenmesi gereken bölümdür.

Node'u sadece bir kullanıcının home dizininde tutmak ve sudo ile işlem yapmamak istiyorsanız nvm:

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

URL içindeki v0.40.1 sürümü bu metin yazıldığında güncel olan sürümdür; en son sürüm için nvm README dosyasını kontrol edin ve çalıştırmadan önce sürümü güncelleyin. nvm bu işlem için avantajlıdır: Node ve global paketlerini ~/.nvm altına kurar, bu nedenle bir sonraki bölümdeki global-install izin sorunu yaşanmaz. nvm yöntemini seçerseniz, npm-prefix adımını atlayabilirsiniz.

sudo npm -g olmadan CLI kurulumu

sudo npm install -g @google/gemini-cli komutu cazip görünebilir. Ancak bunu kullanmayın. Root yetkisine sahip bir global prefix, sonraki tüm kurulumlarda yetki hatalarına yol açar ve npm cache içerisinde aylar sonra sorun çıkaracak root sahipliğinde dosyalar bırakır. Sistem Node sürümüne karşı sudo kullanmadan npm install -g komutunu çalıştırdığınızda şu 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 hata, npm'in kullanıcınızın yetkisi olmayan /usr/lib dizinine yazmaya çalışmasından kaynaklanır. Çözüm sudo kullanmak değildir; npm'in global prefix değerini, global kurulumların sahibi olduğunuz bir dizine yapmasını sağlayacak şekilde ev dizininize yönlendirmektir:

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 kullanımı, ~/.profile yerine bilinçli olarak seçilmiştir: İki bölüm sonra CLI'ı içinde çalıştıracağınız tmux, ~/.bashrc dosyasını okuyan ve ~/.profile dosyasını atlayan bir non-login shell başlatır. Bu nedenle, yanlış dosyadaki bir PATH satırı, gemini içeriğinin tam ihtiyacınız olan yerde görünmez kalmasına neden olur. gemini --version komutunun bir versiyon numarası yazdırması, testin tamamıdır. Eğer bunun yerine gemini: command not found hatası alıyorsanız, PATH export işleminiz gerçekleşmemiştir; hata modlarını inceleyin. nvm kullanıyorsanız, prefix satırlarını tamamen atlayın; nvm zaten global paketleri ev dizininiz altına kurar.

Eğer daha önce sudo npm komutunu çalıştırdıysanız ve şimdi Your cache folder contains root-owned files hatası alıyorsanız, durumu sudo chown -R $(id -u):$(id -g) ~/.npm ile bir kez düzeltin.

Headless kimlik doğrulama sorunu ve çözüm yolları

gemini komutu ilk kez etkileşimli olarak çalıştırıldığında Google hesabınızla giriş yapmanızı teklif eder. Masaüstü bilgisayarlarda bu işlem bir tarayıcı sekmesi açar. Headless VPS sistemlerinde tarayıcı bulunmadığından, akış ya açılması gereken bir localhost URL'si yazdırır ya da şu şekilde hata verir:

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

Sorun redirect_uri=http://localhost:PORT kaynaklıdır. URL'yi dizüstü bilgisayarınızda açıp onaylasanız bile Google, http://localhost:PORT adresine yönlendirme yapar; bu adres sunucu üzerindeki localhost'tur ve dizüstü bilgisayarınızdan bu porta erişilemez. Kimlik doğrulama tamamlanamaz.

Bunu aşmanın iki geçerli yolu vardır.

Birinci yol API anahtarı kullanmaktır ve bu yöntem sunucular için doğru varsayılan yöntemdir. Google AI Studio (aistudio.google.com) üzerinden bir anahtar oluşturun ve bunu CLI'a bir ortam değişkeni olarak iletin; CLI GEMINI_API_KEY değerini okur ve tarayıcı akışını tamamen atlar. "Geçmiş kaydı tutmama ve dünya tarafından okunabilir dosyalardan kaçınma" kuralına dikkat edilmelidir. Komut satırına export GEMINI_API_KEY=AIza... yazmayın; bu değer ~/.bash_history dosyasına açık metin olarak kaydedilir. Anahtarı başkalarının okuyabileceği bir dosyaya koymayın. Anahtarı, kabuğun (shell) başlangıçta kaynak olarak aldığı (source) mode-600 modundaki bir dosyaya yazın:

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 modu, dosyayı sadece kullanıcınızın okuyabileceği anlamına gelir. Anahtarın ortama ulaştığını printenv GEMINI_API_KEY ile doğrulayın; eğer çıktı boşsa CLI tarayıcı akışına döner ve hata verir. Eğer bu düzeni tercih ederseniz, CLI ~/.gemini/ dizinindeki bir .env dosyasını da okur; aynı kural geçerlidir, yani chmod 600 ~/.gemini/.env.

İkinci yol, OAuth geri dönüşünü (callback) dizüstü bilgisayarınıza tünelleyerek kişisel Google hesabı ile girişi (ve ücretsiz katmanı) kullanmaya devam etmektir. Sorun, CLI'ın loopback sunucusunun her çalıştırmada rastgele bir porta bağlanmasıdır; bu nedenle önce OAUTH_CALLBACK_PORT ortam değişkeni ile portu sabitlemeniz ve ardından tam olarak bu portu yönlendirmeniz gerekir:

# 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 tarayıcı açamaz, bu nedenle kimlik doğrulama URL'sini yazdırır; bu URL'yi dizüstü bilgisayarınızdaki tarayıcıda açın ve onaylayın. Google http://localhost:8085/... adresine yönlendirdiğinde, SSH yönlendirmesi bu isteği VPS üzerindeki loopback sunucusuna taşır ve kimlik doğrulama tamamlanır. Portu sabitlemezseniz, her çalıştırmada yeni bir rastgele porta düşer ve önceden kurulmuş hiçbir ssh -L bunu yakalayamaz. Bu yöntem çalışır ancak bir tarayıcı başında oturmayı gerektirir, bu yüzden scriptler için uygun değildir. Sürekli çalışan işlemler için API anahtarı kullanın.

AI Studio yerine Vertex AI veya bir Google Cloud projesi kullanılıyorsa, GOOGLE_API_KEY ile birlikte GOOGLE_GENAI_USE_VERTEXAI=true veya Code Assist lisansı için GOOGLE_CLOUD_PROJECT ayarlanmalıdır; aynı ortam değişkeni disiplini ve aynı mode-600 dosyası geçerlidir.

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

SSH kabuğundan doğrudan başlatılan bir gemini süreci, bu kabuğun bir alt sürecidir. Bağlantı koparsa — dizüstü bilgisayarın kapanması, Wi-Fi bağlantısının kesilmesi veya zaman aşımı — sshd pseudo-terminali kapatır, kabuk SIGHUP sinyali alır ve CLI oturumu sonlandırılır. Dosya düzenleme işleminin onuncu dakikasında çalışan bir görev bu şekilde ölür ve tekrar bağlandığınızda kurtarılacak bir süreç bulunmaz.

tmux, kabuğun sahipliğini sshd yerine üstlenerek bu sorunu çözer. Bu, uzak bir VPS üzerinde tmux içinde bir AI kodlama ajanı çalıştırma ile aynı yöntemdir ve burada da 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 adlı oturuma bağlanır, mevcut değilse yeni bir oturum oluşturur; bu nedenle her girişte çalıştırılması gereken tek komut budur. İçerideki kabuk SSH oturumunuza değil, ayrılmış (detached) tmux sunucusuna aittir; bu sayede bağlantı kopsa bile CLI çalışmaya devam eder. Tekrar bağlanıp oturuma dahil olduğunuzda aynı geçmişe (scrollback) dönersiniz.

Etkileşimli olmayan, betik tabanlı çalıştırmalar için Gemini CLI'ın headless modu mevcuttur: gemini -p "summarise the failing tests in this repo" bir yanıt yazdırır ve çıkar, --output-format json ise başka bir yere yönlendirmek (pipe) için makine tarafından okunabilir çıktı verir. API anahtarı ile headless modu, uzun süreli toplu işler (batch job) çalıştıran bir tmux oturumu veya cron görevi için idealdir. Ancak bir istisna vardır: cron görevleri giriş dosyalarınızı (login files) kaynak olarak almaz (source); bu nedenle crontab satırına kendi GEMINI_API_KEY değerini verin (veya komuta ~/.gemini_env dosyasını source yaptırın), aksi takdirde CLI tarayıcı akışına döner ve hata verir.

Üretim ortamı çalıştıran bir sistemde sandboxing ve izinler

Shell erişimi olan bir agent, bir shell'dir. Gemini CLI komut çalıştırabilir ve varsayılan olarak her riskli işlemden önce onay ister; ancak kullanıcılar --yolo (her araç çağrısını otomatik onayla) seçeneğini kullanabilir. Bu durumda agent, çalıştığı kullanıcının tam yetkisiyle dosyaları silebilir, git üzerinden push yapabilir veya dahili servislere istek gönderebilir. Üretim ortamı çalıştıran bir sistemde bu durum teorik değil, gerçek bir etki alanıdır.

Sağladığı faydaya göre sıralanmış üç kontrol:

• Ayrı ve yetkisiz bir kullanıcı olarak çalıştırın. Root veya sudo üyesi olmamalıdır. Kendi home dizinine sahip bir agent kullanıcısı oluşturun, Node ve CLI'ı buraya kurun; böylece hatalı bir komut sadece bu hesapla sınırlı kalır. Bu, en yüksek değerli karardır.
• Üretim ortamı kimlik bilgilerini sistemde tutmayın. Üretim ortamı ~/.aws/credentials bilgileri, üretim ortamından kopyalanmış .env verileri veya kritik verilere yazma yetkisi olan veritabanı şifreleri bulundurmayın. Agent'a staging veya salt okunur kimlik bilgileri verin.
• Yerleşik sandbox yapısını kullanın. Docker veya Podman yüklü olduğunda, gemini --sandbox (veya GEMINI_SANDBOX=docker) agent'ın araç çağrılarını ana sistem dosya sisteminden ve ağından izole edilmiş bir konteyner içinde çalıştırır. Bu yöntem, yetkisiz kullanıcı kullanımının yerine geçmez; ancak aynı VPS üzerinde gerçek işler yapılıyorsa güçlü bir ikinci katmandır.

Gemini CLI'ı diğer self-hosted araçlarla birlikte çalıştırıyorsanız —örneğin aynı VPS üzerinde araçları agent'a sunan bir MCP server— eklenen her yeteneği agent'ın erişebileceği yeni bir yüzey olarak değerlendirin ve kendisine verilen token kapsamını tam olarak tek bir iş ile sınırlandırın.

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

Kimlik doğrulama yolu, faturalandırma yöntemini belirler. Kişisel bir Google hesabı (OAuth yolu), dakika başına ve gün başına gerçek limitleri olan ücretsiz Gemini Code Assist katmanını kullanır; bu limitler aşılırsa, zaman dilimi sıfırlanana kadar istekler bir rate-limit hatası döndürür. AI Studio'dan alınan bir API anahtarı, projeye bağlı olarak ücretsiz katmanda olabilir veya ücretlendirilebilir; ücretli bir anahtar limitleri artırır ve token başına ücret alır. Vertex ve Cloud-project kimlik doğrulaması ise Google Cloud üzerinden faturalandırılır.

İki pratik not. Döngü halindeki bir unattended agent kotayı hızlıca tüketebilir; bu nedenle bir cron job olarak güvenmeden önce ilk birkaç seferde izlenmelidir. Ayrıca, bir sunucu tarafı model kullanım amacınız Google'ın barındırılan modelleri yerine gizlilik veya ölçülmemiş çıkarım ise, bu farklı bir araçtır — Ollama ile bir VPS üzerinde açık kaynaklı bir LLM'i self-hosting yapmak, Gemini'dan çok daha küçük bir model çalıştırma maliyeti karşılığında, ağırlıkları ve istemleri kendi cihazınızda tutar.

Güncel tutma

Gemini CLI sık sık güncellenir. Kullanıcıya ait bir prefix içine kurulduğu için güncellemeler için sudo gerekmez:

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

Sürüm kanalları mevcuttur: @latest kararlı sürüm, @preview haftalık önizleme sürümü, @nightly ise en yeni özelliklerin bulunduğu sürümdür — güvendiğiniz her şey için @latest sürümüne sabitleme yapın. nvm kullanımında, global paketler aktif Node sürümü altında bulunur; bu nedenle Node sürümünü nvm use ile değiştirdikten sonra CLI'ı yeniden kurmanız gerekebilir. Her yamayı takip etmek yerine sürüm notlarını okuyun.

Hata modları ve tam dize karşılıkları

npm WARN EBADENGINE Unsupported engine ... required: { node: '>=20' }, ardından çalışma zamanında CLI'ın çökmesi. Node sürümü çok eski — dağıtım sürümü 18.19.1 olup destek süresi dolmuştur. NodeSource veya nvm üzerinden Node 20+ sürümünü yükleyin ve node --version ile doğrulayın. Birden fazla Node yüklüyse, which node ifadesinin /usr/bin/node yerine yeni sürümü işaret ettiğinden emin olun.

npm error code EACCES / permission denied, mkdir '/usr/lib/node_modules/...'. Root yetkili bir prefix içine global kurulum yapılması. sudo kullanmayın — npm config set prefix ~/.npm-global ayarını yapın, ~/.npm-global/bin öğesini PATH üzerine ekleyin ve normal kullanıcınızla yeniden yükleyin. Önceki bir sudo npm işlemi root yetkili ö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, askıda kalan bir oturum veya erişilemeyen bir redirect_uri=http://localhost:PORT. OAuth akışı, sunucuda bulunmayan bir tarayıcı gerektirir; localhost geri dönüşü sunucuyu, dizüstü bilgisayarınızı değil işaret eder. API-key yöntemini (GEMINI_API_KEY) kullanın veya OAUTH_CALLBACK_PORT öğesini sabitleyin, ssh -L ile SSH üzerinden yönlendirin ve URL'yi yerel olarak 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ç o kabuğun bir alt süreciydi ve bağlantı kesildiğinde pty ile birlikte sonlandı. Kurtarılacak bir veri yoktur. Her oturuma tmux new -A -s gemini ile başlayın ve CLI'ı bunun içinde çalıştırın.

Anahtar tanımlanmış olmasına rağmen kimlik doğrulama hala başarısız oluyor — CLI tekrar kimlik doğrulama seçicisine dönüyor veya bir istek HTTP 400 ile API key not valid hatası döndürüyor. Anahtar, CLI'ın gördüğü ortam değişkenleri içinde değildir. printenv GEMINI_API_KEY ile doğrulayın; eğer boşsa, ~/.gemini_env öğesi kaynak olarak yüklenmemiştir — satırın ~/.bashrc içinde olup olmadığını kontrol edin; etkileşimli kabuklar (tmux dahil) bunu okur ancak cron ve diğer etkileşimli olmayan kabuklar okumaz. Anahtar değeri içindeki hatalı 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ın kullandığı katmanın kotasına ulaşıldı. Pencerenin sıfırlanmasını bekleyin, ajanı yavaşlatın veya ücretli bir API anahtarına geçin. Yeniden deneme döngüsünde takılan bir ajan sürekli bu hatayı alır; ajanı durdurun ve ne yaptığını kontrol edin.

FAQ

Gemini CLI headless sunucuda nasıl kimlik doğrulanır?

Tarayıcı girişi yerine API key kullanın. Google AI Studio üzerinden bir key oluşturun, bu key'i kabuğunuzun (shell) kaynak gösterdiği (export GEMINI_API_KEY=...) bir mode-600 dosyasına ekleyin; böylece CLI, OAuth tarayıcı akışını tamamen atlar. Eğer özellikle kişisel hesap ücretsiz katmanını kullanmak istiyorsanız, loopback portunu OAUTH_CALLBACK_PORT=8085 ile sabitleyin, bu portu ssh -L 8085:localhost:8085 user@server ile dizüstü bilgisayarınıza yönlendirin ve yerel olarak yazdırılan URL'yi açın; ancak bu işlem tarayıcı başında olmayı gerektirdiğinden scriptler için uygun değildir.

npm global kurulumu neden sudo gerektiriyor ve bu durum nasıl önlenir?

Çünkü npm'in varsayılan global prefix değeri /usr/lib/node_modules olarak ayarlanmıştır ve kullanıcınızın bu dizine yazma yetkisi yoktur; bu nedenle düz bir npm install -g işlemi EACCES hatası verir. Yanlış çözüm olan sudo npm -g, daha sonraki kurulumları bozacak şekilde root sahipliğinde dosyalar bırakır. Doğru çözüm, prefix değerini home dizininize (npm config set prefix ~/.npm-global) yönlendirmek ve bu dizinin bin yolunu PATH içine eklemektir; alternatif olarak, global paketleri otomatik olarak home dizininize kuran nvm kullanılabilir.

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

İşlemi tmux içinde çalıştırın. SSH kabuğundan başlatılan bir süreç, bağlantı koptuğunda o kabuğun alt süreci olduğu için sonlanır; tmux ise kabuğu, bağlantı kopsa bile hayatta kalan ayrılmış (detached) bir sunucu altında çalıştırır. tmux new -A -s gemini komutunu kullanın, içeride gemini komutunu çalıştırın, Ctrl-b d ile 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 mi?

Sadece dikkatli kullanıldığında güvenlidir; çünkü kabuk erişimi olan bir ajan, çalıştığı kullanıcının sahip olduğu tüm yetkilere sahip olabilir. Uygulamayı sudo yetkisi olmayan, özel bir yetkisiz kullanıcı olarak çalıştırın, üretim kimlik bilgilerini makinede tutmayın, --yolo otomatik onaylamasından kaçının ve araç çağrılarını host sistemden izole etmek için --sandbox (Docker veya Podman) kullanın. Çalıştığı hesabın yetkileri, ayarladığınız herhangi bir flag'den daha kritiktir.

Gemini CLI için herhangi bir firewall portu açmam gerekiyor mu?

Hayır. Bu araç, Google API'lerine giden (outbound) HTTPS çağrıları yapan bir istemcidir; bu nedenle sadece 443 numaralı outbound portuna ihtiyaç duyar, inbound port açılmasına gerek yoktur. Eğer OAuth tünelini kullanıyorsanız, sabitlenmiş callback portu (örneğin 8085) localhost üzerinde kalır ve açık bir inbound port yerine SSH yönlendirmesi üzerinden erişilir. Gelen (inbound) bağlantıları kapalı tutun.