OpenAI Codex Desktop hatası macOS disklerini gigabaytlarca crash dump ile dolduruyor

Codex Desktop sessizce disk alanını yiyor

Hacker News'in ana sayfasına düşen, OpenAI'nin herkese açık codex repository'sindeki bir hata bildirimine göre, OpenAI'nin macOS için Codex Desktop uygulaması tamamen kullanılabilir kalırken arka planda günde gigabaytlarca crash raporu üretiyor. Sorun uygulamanın çökmesi değil; uygulamanın crash raporlama mekanizmasının sınır olmaksızın kontrolden çıkmış görünmesi — kuyruğu sınırlayacak bir üst limit, yükleme veya temizleme yok.

Kullanıcıların gördüğü

2 Haziran 2026'da açılan orijinal bildirim, ~/Library/Application Support/com.openai.codex/web/Crashpad/pending altında eşleşen .dmp ve _sidecar.json dosyalarının biriktiğini anlatıyor. Bildirimi yapan kullanıcının makinesinde bu dizin tek günde 4.9GB ve 54.504 dosyaya ulaştı — 27.252 dump artı 27.252 sidecar — ve sorun incelenirken sayı artmaya devam etti. 30 Mayıs'tan beri iki browser_crashpad_handler süreci çalışıyordu ve ikisi de aynı Crashpad veritabanını hedefliyordu.

Bekleyen dosyaları silmek alanı hemen geri kazandırdı ve dizin 6.4MB'a düştü, ama yeni dump ve sidecar çiftleri hemen yeniden belirdi.

Diğer kullanıcılar sorunu çok daha büyük ölçekte yeniden üretti. Bir yorumcu 59GB biriktiğini bildirdi ve 65.535 dosya sınırı dedikleri sınıra ulaşınca arka plan sürecinin daha fazlasını yazmaya devam ettiğini söyledi. Daha yeni bir sürümü (26.602.71036) kullanan başka bir kullanıcı, önceki 24 saatte yazılan 98.218'i de içeren 738.864 dosyada yaklaşık 61GB (58.89GiB) ölçtü. Temizlik, yeniden yükleme ve yeniden başlatmadan sonra dizin saniyede yaklaşık bir crash raporu hızıyla büyüdü. Etkilenen sürümler 26.527.60818 ve 26.602.71036 arasını kapsıyor.

Crash handler'ın crash döngüsüne girdiği görünüyor

En yararlı tanı ipucu dump'ların kendisinde. GitHub issue'suna göre en yeni .dmp dosyaları browser_crashpad_handler'dan bir FATAL mesajı içeriyor — mach_port_request_notification "invalid capability" hatası döndürdükten sonra başarısız olan bir "kr == KERN_SUCCESS" kontrolü. macOS sistem günlükleri aynı yardımcı sürecin EXC_BREAKPOINT / SIGTRAP istisnalarıyla tekrar tekrar öldüğünü gösteriyor.

Başka bir deyişle, çökmeleri yakalamaktan sorumlu bileşen bir döngü içinde çöküyor ve her yinelemede kendisi hakkında sadakatle bir crash raporu yazıyor. Bir raporlayıcı ayrıca, dump fırtınası başlamadan kısa süre önce uygulama içi tarayıcı özelliğinin kullanılamaz hale geldiğini belirtti; bu da tarayıcı, Chromium ve Crashpad yolunun işin içinde olduğunu düşündürüyor, ancak bu bağlantı doğrulanmış değil.

Geçici çözümler

Etkilenen kullanıcılar için yeniden yükleme de paket tarayıcı backend'lerini devre dışı bırakmak da büyümeyi durdurmadı. Bir raporlayıcı paket tarayıcı ve Chrome entegrasyonlarını devre dışı bırakmayı ve ~/.codex/config.toml içinde BROWSER_USE_AVAILABLE_BACKENDS'i boş diziye ayarlamayı denedi; yeniden başlatmadan sonra etkisi olmadı. macOS, sudo ile bile handler binary'sini değiştirmeyi reddetti ve "Operation not permitted" döndürdü.

Sonunda işe yarayan, browser_crashpad_handler süreçlerini öldürmek ve kullanıcı düzeyindeki Crashpad veritabanı dizinini salt okunur ve değiştirilemez yapmak oldu. Bu, disk büyümesini durduruyor ama bedeli uygulama için crash raporlamanın devre dışı kalması. Issue başlığı ayrıca uygulama güncellemelerinden sonra geride kalan bayat Crashpad helper'ları ve sahipsiz kalmış Codex süreçlerine ilişkin daha önceki bildirimlere bağlanıyor; bu da masaüstü uygulamasında daha geniş bir süreç yaşam döngüsü sorununa işaret ediyor.

Neden önemli

Bu sessiz bir başarısızlık biçimi: uygulama disk alanını günler içinde onlarca gigabayt doldurabilecek bir hızla tüketirken normal görünüyor ve normal çalışıyor. Gizli application-support dizinlerini hiç incelemeyen kullanıcıların elinde, disk baskısı başka yerde ortaya çıkana kadar bariz bir sinyal yok.

Ayrıca bir gizlilik boyutu da var. Orijinal raporlayıcı minidump'ları yayınlamayı bilinçli olarak reddetti, çünkü bunlar bellek içerikleri, yerel dosya yolları ve diğer özel verileri içerebilir — ve bu hatada bu dump'lar sürekli üretiliyor ve yönetilen bir hat üzerinden yüklenmek yerine diskte bırakılıyor.

OpenAI bir düzeltme yayınlamadan önce, Codex Desktop çalıştıran macOS kullanıcıları Crashpad pending dizininin boyutunu kontrol edebilir ve hızlı büyümeyi etkilendiklerinin bir işareti olarak değerlendirebilir. Bildirim anında, satıcı tarafında bir düzeltmeye dair bir işaret yoktu; yalnızca salt okunur geçici çözüm vardı.