Codex logging bug स्थानीय SSD पर TB-स्तर की writes पैदा कर सकता है, जिससे SSD की उम्र तेज़ी से घट सकती है

 (github.com/openai)
1 पॉइंट द्वारा GN⁺ 4 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Codex लोकल SQLite feedback log DB में लगातार बड़ी मात्रा में डेटा लिखता रहा, और एक उपयोगकर्ता के environment में 21 दिन चलने के बाद मुख्य SSD पर लगभग 37TB लिखा गया
  • इसे सालाना आधार पर देखें तो यह लगभग 640TB है, जो 1TB SSD के लिए साल में लगभग 640 full-drive writes के बराबर है, और कुछ consumer SSDs की warranty endurance (लगभग 600 TBW) को 1 साल से कम में खत्म कर सकता है
  • संरक्षित rows केवल लगभग 5 लाख हैं, लेकिन AUTOINCREMENT counter 5.5 अरब IDs से आगे बढ़ गया, जिससे retained rows और cumulative inserted IDs के बीच लगभग 10,000x का अंतर दिखता है
  • कारण यह है कि SQLite feedback log sync को global TRACE default(Targets::new().with_default(Level::TRACE)) के साथ सेट किया गया था, इसलिए dependencies के internal logs और बड़े raw protocol payloads तक सब कुछ स्थायी रूप से रिकॉर्ड हो रहा था
  • 22 जून 2026 को दो PR merge किए गए, जिनसे लगभग 85% logs रुक गए और issue बंद कर दिया गया

मुख्य लक्षण और प्रभाव का दायरा

  • Codex लगातार निम्न फ़ाइलों में बड़ी मात्रा में writes कर रहा था
    • ~/.codex/logs_2.sqlite
    • ~/.codex/logs_2.sqlite-wal
    • ~/.codex/logs_2.sqlite-shm
  • 21 दिन चलने के बाद मुख्य SSD पर लगभग 37TB लिखा गया, और process/file-स्तर की जाँच में Codex SQLite logs को प्रमुख लगातार write source के रूप में पहचाना गया
  • इसका वार्षिक अनुमान लगभग 640TB है, जो 1TB SSD के लिए सालाना लगभग 640 बार पूरे drive write के स्तर के बराबर है
  • कुछ consumer SSDs की rating लगभग 600 TBW होती है, इसलिए उनकी warranty write life 1 साल से कम में समाप्त हो सकती है

प्रमाण डेटा

  • Evidence1 — write amplification

    • वर्तमान logs_2.sqlite फ़ाइल आकार: 1.2 GiB
    • वर्तमान retained rows: 506,149
    • cumulative allocated row id: 5,543,677,486
    • retained rows (लगभग 0.5M) और cumulative inserted IDs (5.5 अरब+) के बीच लगभग 10,000x का अंतर है; WAL, indexes, pruning, checkpoints, page rewrites और device-level amplification को हटाकर भी 10TB+ स्तर के पुराने log churn का अनुमान बनता है

  • Evidence2 — level/target distribution

    • retained rows 681,774, अनुमानित retained log content लगभग 1,035.6 MiB
    • level के अनुसार हिस्सा: TRACE 70.7%, INFO 25.7%, DEBUG 3.0%, WARN 0.6%
    • सबसे बड़े target+level pairs
      • codex_api::endpoint::responses_websocket (TRACE) 527.4 MiB
      • codex_otel.log_only (INFO) 141.2 MiB
      • codex_otel.trace_safe (INFO) 121.2 MiB
      • log (TRACE) 97.4 MiB
    • शीर्ष sources में global TRACE logs, mirrored telemetry logs, और raw websocket/SSE payload recording का हिस्सा सबसे अधिक था
    • codex_otel.log_only + codex_otel.trace_safe अतिरिक्त 25.3% लेते हैं; इन categories को filter करने पर sample के आधार पर retained log bytes का लगभग 96% हटाया जा सकता है
    • सबसे अधिक बार आने वाला TRACE source (target=log) कई low-level items से भरा था, जैसे inotify event (उदाहरण: ld.so.cache 128,764 बार), tokio-tungstenite internal calls, WouldBlock आदि

  • write amplification measurement

    • 15-second sample में retained rows 681,774 पर स्थिर रहे, जबकि लगभग 36,211 rows insert हुए
    • बार-बार होने वाला insert-and-prune pattern—insert → indexing → WAL write → pruning—write amplification पैदा कर रहा था

अनुमानित कारण

  • SQLite feedback log sink को global TRACE default(Targets::new().with_default(Level::TRACE)) के साथ install किया गया था
  • इसके कारण dependencies/internal logs और बड़े raw protocol payloads सहित हर target TRACE level पर स्थायी रूप से store हो रहा था

प्रस्तावित सुधार की दिशा

  • feedback logs को रखा जाए, लेकिन default persistent storage का दायरा कम किया जाए
    • SQLite feedback log sink में global TRACE का उपयोग न किया जाए
    • target=log, hyper_util, tokio-tungstenite internals, inotify spam, low-level OpenTelemetry SDK logs जैसे low-value noise के लिए threshold बढ़ाया जाए या उन्हें हटाया जाए
    • raw websocket/SSE payloads को पूरा store करने के बजाय summary store की जाए (event type, elapsed time, success/failure, token usage, payload byte length)
    • codex_otel.log_only / codex_otel.trace_safe mirrored events को debugging में स्पष्ट उपयोग न हो तो store करने से बचा जाए
    • केवल thread-level cap पर्याप्त नहीं है, इसलिए global log DB size/write limit भी जोड़ी जाए
  • sqlite_logs_enabled = false जैसा option भी उपयोगी हो सकता है, लेकिन मूल समाधान बेहतर default filtering है

multi-platform reproduction reports

  • macOS

    • macOS 15.7.7 / Codex 26.616.51431 environment में logs_2.sqlite 113M, MAX(id)=34,277,360 के साथ retained rows 31,405 थे, और 60-second sample के 2 runs में लगभग 60 writes प्रति second देखे गए
    • 1–2 घंटे के session के दौरान codex process द्वारा लगभग 50GB लिखे जाने का मामला भी रिपोर्ट हुआ

  • Windows

    • Windows Codex Desktop(codex.exe app-server --analytics-default-enabled) में RUST_LOG=warn और explicit trace setting न होने पर भी TRACE rows लगातार insert होते रहे
    • retained rows लगभग 71k थे, जबकि sqlite_sequence में logs value 1.85 करोड़ से अधिक थी, जो बड़े पैमाने पर पुराने insert/prune churn को दिखाती है
    • 10-minute distribution में TRACE 1,812 rows थे, और शीर्ष TRACE targets में codex_api::endpoint::responses_websocket(3.5MB+), codex_api::sse::responses शामिल थे
    • अपेक्षित व्यवहार: RUST_LOG=warn होने पर dependencies/internal TRACE और बड़े payloads को लगातार store नहीं किया जाना चाहिए

अतिरिक्त जोखिम और अस्थायी mitigation

  • data loss risk

    • disk भर जाने की स्थिति में reboot के बाद Linux login fail हो सकता है
    • Codex /goal mode disk space खाली करने की कोशिश में files/folders delete कर सकता है, जिससे data loss हो सकता है

  • temporary mitigation scripts

    • चल रहे WAL को trim करने के लिए trim-codex-wal.sh (PRAGMA wal_checkpoint(TRUNCATE) का उपयोग), जिसे cron से हर 15 मिनट में चलाया जा सकता है
    • log/WAL files delete करने और Codex-संबंधित processes को SIGTERM→SIGKILL भेजकर disk space तुरंत खाली करने के लिए fix-codex-wal.sh
    • यदि SQLite trigger block_log_inserts जोड़कर logs table inserts को ignore कर दिया जाए, तो WAL growth रुक जाती है; वापस लेने के लिए DROP TRIGGER IF EXISTS block_log_inserts
      • VACUUM DB को फिर से लिखता है, इसलिए बड़ी files में यह एक बार में बहुत बड़ी write पैदा कर सकता है; इसलिए trigger जोड़ने और WAL growth रुकने की पुष्टि के बाद DELETE/VACUUM चलाने की सलाह दी गई
      • क्योंकि यह private SQLite schema modification है, भविष्य के Codex updates/migrations table को फिर से बना सकते हैं, trigger हटा सकते हैं, या व्यवहार बदल सकते हैं
    • स्थायी fix आने तक SSD wear से बचने के लिए इस DB को ramdisk पर रखने का तरीका भी सुझाया गया

समाधान और समापन

  • 22 जून 2026 को दो PR merge होने से लगभग 85% log reduction हुआ, और इसके बाद issue को resolved मानकर बंद किया गया
    • सभी Responses WebSocket event logging बंद (#29432)
    • persistent logs में noise targets filtering (#29457)
  • एक अलग प्रस्तावित patch में global TRACE की जगह default persistence को INFO+ रखा गया, और codex_otel.log_only, codex_otel.trace_safe, hyper_util, log, opentelemetry_sdk आदि को WARN+ तक बढ़ाया गया
  • fixes rust-v0.142.0 में release किए गए

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 4 시간 전
Hacker News की राय

  • मुझे लगता है Codex slopware के बदनाम उदाहरणों में से एक है
    macOS पर सिर्फ विंडो खुली छोड़ देने पर भी spinner message दिखाने के लिए GPU 100% इस्तेमाल करता है
    MBP M5 पर सिर्फ spinner message से GPU 100% दिख जाता है, और मॉडल का इंतज़ार करने के ज़्यादातर समय फैन तेज़ चलता रहता है, इसलिए बैटरी पर इस्तेमाल करते समय सावधान रहना चाहिए
    यह issue GitHub पर आए हुए लगभग 6 महीने हो चुके हैं, और शायद यह उस समय से है जब vibe coding से बना यह कबाड़ रिलीज़ किया गया था
    अगर खुद ठीक करना भी चाहें तो किसी वजह से यह closed source है, इसलिए मुमकिन नहीं
    कौन-सा मॉडल बेहतर है, vibe coding संभव है या नहीं, इस पर बहुत बहस होती है, लेकिन फंडिंग, लोगों और model capability के हिसाब से सबसे संसाधन-संपन्न कंपनियों में से एक अगर vibe coding से बस इतना ही कर पा रही है, तो स्तर यही है
    जब CEO पहले ही कह चुका है कि वह “coding पर फोकस” कर रहा है, तब इस तरह की गंभीर गलती कंपनी के भीतर कुछ सचमुच टूट जाने का संकेत लगती है, और Polymarket पर भी लगभग कोई नहीं मान रहा कि OpenAI जल्द कोई leading model निकालेगा
    दुनिया को Anthropic के एक competitor की ज़रूरत है, इसलिए यह दुखद है

    • बगल में Claude Code भी है, इसलिए slopware के उदाहरणों में उसे छोड़ना नहीं चाहिए
    • अगर AI से 10x productivity आती है और हम AGI या ASI के इतने क़रीब हैं, तो समझ नहीं आता कि Codex या Claude Code CLI जैसे products अभी भी इतने घटिया कैसे हो सकते हैं
      लगता है कि “agentic AI revolution” को अब तक ऐसी समस्याएँ हल कर देनी चाहिए थीं
      उम्मीद है अंदरूनी तौर पर यह “प्रोसेस हो रहा है, कृपया इंतज़ार करें” या “यह काम बहुत मुश्किल है” जैसा तो नहीं कह रहा होगा
    • जब मैं ऐसे संगठन में काम करता था जो मूलतः सब कुछ open source में जारी करता था, तब side project समेत किसी चीज़ को private रखने की सिर्फ एक वजह होती थी: शर्म
      कोई भी घटिया codebase का सार्वजनिक चेहरा नहीं बनना चाहता
      और अगर उसी code से बेहूदा pricing को सही ठहराया जा रहा हो, तो वह बोझ शायद तीन गुना ज़्यादा लगता है
    • सिर्फ Codex ही नहीं, macOS का ChatGPT app भी कुछ घंटों तक खुला छोड़ दो तो समय के साथ 60GB RAM खा जाता है और बाकी apps को मार देता है
      समझ से बाहर है
      browser में Google AI Studio चलाने की कोशिश करो तो वह भी CPU 100% इस्तेमाल करता है
      आख़िर में लगता है कि सब कुछ खुद app बनाकर ही करना पड़ेगा
    • शुरुआत में लोग कहते थे कि दुनिया को ChatGPT के competitor के तौर पर Anthropic चाहिए, और अब बात पूरी तरह घूमकर वापस आ गई है

  • X पर इस समस्या का एक अस्थायी workaround पोस्ट किया गया है[1]
    sqlite3 ~/.codex/logs_2.sqlite "CREATE TRIGGER IF NOT EXISTS block_log_inserts BEFORE INSERT ON logs BEGIN SELECT RAISE(IGNORE); END;"
    और एक notebook पर उस sqlite file पर VACUUM FULL चलाने से उसका आकार 27GB से घटकर 73MB हो गया[2]
    [1]: https://xcancel.com/bdsqlsz/status/2067964486615810369
    [2]: https://xcancel.com/jeethu/status/2068087449469780434

    • इस बार भी database-level rule ने दिन बचा लिया
    • असली समाधान है इस्तेमाल बंद करना और Pi पर चले जाना

  • सब लोग OpenAI की आलोचना कर रहे हैं, और वजह भी है, लेकिन Claude Code के उलट Codex आधिकारिक रूप से customizable है, यह याद रखने लायक है: https://github.com/openai/codex
    patch करना भी काफ़ी आसान है

    • वह CLI है, यहाँ जिस proprietary Codex app की बात हो रही है, वह नहीं

  • यह चौंकाने वाला है
    issue खुले एक हफ़्ता हो गया, और मुझे तो लगता है OpenAI बस चुप है
    समझ नहीं आता, मुझे लगा था ऐसे vendors इस तरह की समस्याओं को लेकर बेहद संवेदनशील होंगे
    जाहिर है इन्होंने GitHub पर potential issues को मॉनिटर करने और fixes सुझाने के लिए कई agents लगा रखे होंगे? …होंगे न?
    अपने ही tools चलाकर GitHub issues को real time में ठीक करना तो इनके लिए मामूली बात होनी चाहिए

    • लगता है OpenAI issue fix करने में काफ़ी कमज़ोर है
      मेरा पसंदीदा उदाहरण #2472 है; GPT-5 launch stage पर इसे “fix” किया हुआ दिखाया गया था, लेकिन ticket अभी भी खुला है और वह “fix” अभी तक merge भी नहीं हुआ
      इस बात की ओर इशारा करने वाली मूल पोस्ट है https://blog.tymscar.com/posts/openaiunmergeddemo/ और issue है https://github.com/openai/openai-python/issues/2472
    • इसी समस्या पर GitHub issue अप्रैल से मौजूद था
      मैं Codex का बहुत इस्तेमाल कर रहा हूँ और उसकी performance (UX और output) से काफ़ी संतुष्ट हूँ, लेकिन यह समझना मुश्किल है कि उन्होंने अभी तक इस समस्या को ठीक क्यों नहीं किया

  • लगता है यह समस्या ठीक कर दी गई है[0], और शायद अगली release में आएगी
    [0] https://github.com/openai/codex/commit/e98d43ac372ddf7f513c0...

  • vibe coding ने “तेज़ी से आगे बढ़ो और चीज़ें तोड़ो” को बिल्कुल दूसरे स्तर पर पहुँचा दिया है

    • अभी हमारी कंपनी में किसी का vibe-coded कचरा बुरी तरह गड़बड़ा गया है और हम एक बड़े outage से जूझ रहे हैं
    • अब तोड़ने के लिए चीज़ें भी धीरे-धीरे कम पड़ रही हैं
    • अगर technical debt न हो, तो vibe coding आम तौर पर prototyping के लिए उपयोगी है
      असली products में वास्तविक software engineers की जगह यह कभी नहीं ले पाएगा

  • थोड़ा विषय से हटकर, लेकिन इन कंपनियों को repository root folder को Claude.md या copilot.md जैसी files से गंदा करना बंद करना चाहिए
    सबको मिलकर docs/llm/* जैसा कोई जाना-पहचाना folder structure तय करना चाहिए

  • पिछले साल के अंत में जब Claude Code latency की वजह से बुरी हालत में था, तब OpenAI ने लगभग हाथ आई जीत गँवा दी
    आजकल Codex शुरू होते ही typing latency देता है, जबकि Claude Code कभी-कभी अटकता ज़रूर है, लेकिन आम तौर पर मैं key दबाता हूँ तो… सचमुच… वही दिखता है जो दबाया

    • मेरे मामले में तो बिल्कुल उल्टा है
    • मुझे Claude Code लगभग इस्तेमाल लायक नहीं लगता
      कुछ शब्दों से ज़्यादा टाइप करना हो तो हमेशा neovim में लिखना पड़ता है

  • यह दरअसल बहुत ही सामान्य तरह की गलती है
    सब कुछ चालू रखते हुए trace/debug logs के साथ release कर दिया गया, लेकिन मज़ेदार बात यह है कि इसका असर सामान्य तरीके से सामने नहीं आता
    पहले के समय में कोई developer trace-level logging चालू छोड़ देता तो app विनाशकारी रूप से धीमा हो जाता और अगली update में तुरंत ठीक कर दिया जाता, लेकिन अब memory, CPU speed और disk speed इतनी ज़्यादा बेहतर हो चुकी हैं कि हम उस बिंदु पर पहुँच गए हैं जहाँ यह तुरंत उस रूप में दिखता ही नहीं — यह पागलपन है

    • इसमें यह बात भी योगदान देती है कि agent work server side पर होता है, इसलिए thin client के लिए local resources को पूरा चाट जाना मानो स्वीकार्य हो गया है

  • काश कोई इस जुझारू startup को कुछ tokens दान कर दे। लगता है मदद की ज़रूरत है