OpenAI'ın Codex CLI'si terminali kapattıktan sonra kendi kendini güncelleyen bir daemon bırakıyor

Geliştiriciler, OpenAI'ın Codex CLI'sinin tüm terminal pencereleri kapatıldıktan sonra çalışmaya devam eden bir arka plan daemon'u başlattığını belirtti ve bağımsız bir yeniden üretim bu davranışı doğruladı. Neeraj Sharma'nın dev.to'daki yazısına göre, rapor ilk olarak OpenAI'ın codex deposunda daemon'un opt-in hale getirilmesi talebiyle açılan bir GitHub issue olarak ortaya çıktı ve tartışma Hacker News'in zirvesine ulaştı. 0.157.0 sürümünden itibaren codex'i etkileşimli olarak başlatmak ayrıca bir backend süreci başlatıyor, ev dizinine yaklaşık 374 MB ikili dosya kopyalıyor ve kendini belirli bir programla güncelliyor.

Gerçekte ne çalışıyor

Sharma, 13 Ekim 2026'da ev dizini boş olan temiz bir Linux container'ına Codex CLI 0.157.0 kurdu ve daemon'u başlattı. Araç ~/.codex/packages/app-server-daemon altına bir paket kurdu ve başlatılmış bir backend bildirdi. Bir süreç listesi daha sonra, her ikisi de ana PID 1'e sahip iki süreç gösterdi: backend'in kendisi ve pid-update-loop etiketli bir güncelleyici. Ana süreçlerinin herhangi bir shell değil init süreci olması nedeniyle terminali kapatmak onları durdurmuyor.

GitHub issue'ya göre güncelleyici, başladıktan beş dakika sonra ve ardından her saat başında yeni bir sürüm kontrol ediyor, tam platform paketini yeni bir releases klasörüne indiriyor ve backend'i yeniden başlatıyor; bu da hâlâ çalışan bir turn'u kesebiliyor. Sharma, ~/.codex/packages altında issue ile eşleşen şekilde 374 MB ölçtü, ancak güncelleme döngüsünü izlemek için bir saat beklemediğini belirtti. Net etkisi, CLI'ın npm, brew veya başka bir paket yöneticisinin kurduğu yerden değil, ev dizininden çalışan ikinci bir kopyası.

Stop komutu bir süreci geride bırakıyor

Sharma ayrıca issue'daki, codex app-server daemon stop komutunun backend'i durdurduğu ama güncelleme döngüsünü yetim süreç olarak bıraktığı iddiasını da yeniden üretti. Tamamen kaldırmak için bu sürecin elle kill edilmesi gerekiyor.

Güvenlik ekipleri için sorular

dev.to yazısı, iş yeriyle ilgili endişeleri her diğer geliştirici aracı için genellikle net cevabı olan üç soru olarak çerçeveliyor:

• Hangi sürüm çalışıyor? Daemon, ev dizinindeki bir kopyadan kendini güncelliyor; dolayısıyla bir paket yöneticisinin sabitlediği sürüm, işi yapan sürüm olmayabilir. Issue'yu açan kişi ikisinin birbirinden sapabileceğini tespit etti.
• Hangi ortamı kullanıyor? Issue, daemon'un kendisini başlatan oturumun ortamını koruduğunu bildiriyor; bu nedenle ilk oturumdan gelen proxy ayarları kalıcı olurken sonraki oturumlardaki ayarlar yok sayılıyor. Bu, şirketlerin trafiği inceleyen bir proxy üzerinden yönlendirdiği yerlerde önemli.
• Kim onayladı? Güvenlik ekipleri genellikle kalıcı olan ve kendini güncelleyen yazılımlar üzerinde görünürlük ister ve opt-out varsayılanı, birçok geliştiricinin varlığından haberdar olmayacağı anlamına geliyor.

Sharma, daemon'un kötü niyetli olduğuna dair bir şey bulunmadığını açıkça belirtiyor. Uzun süre çalışan bir backend oturumların daha hızlı başlamasını sağlayabilir ve birkaç istemcinin state paylaşmasına izin verebilir; itiraz, varsayılana ve kapama anahtarının çoğu kişinin bakacağı yerde olmamasına.

Nasıl kapatılır

0.157.0'da bir feature flag mevcut. codex features disable daemon_auto_start komutunu çalıştırmak ~/.codex/config.toml dosyasına daemon_auto_start = false yazıyor ve issue'yu açan kişi, bundan sonra yeni bir oturumun daemon başlatmadığını doğruluyor. Mevcut süreçler yine de temizlik gerektiriyor: stop komutunu çalıştırın, ardından yetim kalan güncelleyiciyi, örneğin app-server daemon pid-update-loop ile eşleşen bir pkill deseniyle kill edin. Disk alanını geri kazanmak için her iki süreç de gittikten sonra ~/.codex/packages/app-server-daemon klasörünü silin.

Daha geniş bir denetim betiği

Codex çoğu makinedeki tek AI kodlama aracı olmadığından Sharma, macOS ve Linux için codex, claude, cursor, gemini, aider, copilot, windsurf ve opencode gibi yaygın AI CLI'larının yetim süreçlerini, kendi kendini yöneten kopyalarının tükettiği diski ve bunlardan bahseden login öğelerini veya servisleri listeleyen salt-okunur bir bash betiği yayınladı. Test container'ında yetim kalan güncelleyiciyi ve 374 MB'lık paketi işaretledi. Betiğin süreç kontrolünün isimlere göre eşleştiği için çıktının beklenen süreçleri içerebileceğini ve herhangi bir şey kill edilmeden önce okunması gerektiği konusunda uyarıyor.

Neden önemli

AI kodlama asistanları yenilikten varsayılan kuruluma geçiyor ve giderek artan şekilde geleneksel geliştirici araçlarının yalnızca açıkça onaylanan servislere ayırdığı kalıcılık, kendini güncelleme ve arka planda çalıştırma gibi davranışlarla geliyorlar. Terminalden daha uzun yaşayan, ilk oturumun ortamını miras alan ve kendi ikili dosyalarını saatlik olarak değiştiren bir daemon, sürüm sabitleme, değişiklik kontrolü ve endpoint izlemenin dışında yer alıyor. Buradaki çözüm tek bir config flag'i, ama yalnızca varlığından haberdar olanlar için. Herhangi bir AI geliştirici aracını onaylamadan önce kontrol listesine "kalıcı mı, kendini güncelliyor mu?" sorusunu eklemek makul bir asgari standart ve Sharma'nın betiği buna hızlı bir başlangıç sunuyor.