- रिपोर्ट के अनुसार, जब Codex CLI Resume किए गए लंबे session में बार-बार Subagent बनाता है, तो
~/.codex/sessionsके नीचे JSONL session files असामान्य रूप से बढ़ने लगती हैं - सार्वजनिक मामले में, एक Resume किए गए parent session से 2,393 Subagent session files बनीं, और इन files ने लगभग 731.5GiB जगह घेर ली
- कुल Codex session data लगभग 755GiB तक बढ़ गया, और 1.8TiB APFS volume का उपयोग 99~100% तक पहुंच गया
- छोटे Subagent sessions में भी लाखों के करीब events रिकॉर्ड हुए, और दूसरे sessions में
compactedhistory तथा Tool output बार-बार सैकड़ों MB के स्तर पर सेव हुए - यह समस्या हालिया मामले में Codex CLI 0.144.6 पर भी पुष्टि हुई, और संबंधित GitHub issue 20 जुलाई 2026 तक खुला है
समस्या के लक्षण
Codex CLI session को दोबारा खोलने के लिए बातचीत और execution history को नीचे दिए गए path में JSONL format में सेव करता है।
~/.codex/sessions/YYYY/MM/DD/rollout-*.jsonl
18 जुलाई 2026 को दर्ज किए गए मामले में ~/.codex का कुल आकार लगभग 760GiB था, जिसमें ~/.codex/sessions अकेले लगभग 755GiB था, और सिर्फ जुलाई के sessions लगभग 734GiB ले रहे थे।
760G ~/.codex
755G ~/.codex/sessions
734G ~/.codex/sessions/2026/07
यह data cache नहीं बल्कि codex resume में इस्तेमाल होने वाला session history है, इसलिए files हटाने पर पुराने sessions दोबारा नहीं खुल पाएंगे। रिपोर्ट के समय कई Codex processes इन JSONL files को लगातार खुले रखे हुए थे।
यह कितनी तेजी से बढ़ा
उस मामले की जुलाई directory में लगभग 2,931 session files थीं, जिनमें से 797 files का आकार 400MiB से अधिक था। अनुमान के अनुसार 11 जुलाई को एक ही दिन में लगभग 109.1GiB और 12 जुलाई को लगभग 149.2GiB session data बना।
तारीख session files 400MiB से अधिक अनुमानित आकार
10 जुलाई 50 0 2.8GiB
11 जुलाई 473 0 109.1GiB
12 जुलाई 506 0 149.2GiB
15 जुलाई 340 265 108.6GiB
16 जुलाई 355 263 109.0GiB
17 जुलाई 300 189 81.7GiB
जगह का अधिकांश हिस्सा एक Resume किए गए parent session से जुड़ा था। इस parent session ने 2,393 Subagent JSONL files बनाई थीं, और इनका कुल logical size लगभग 731.5GiB था। जांच के समय parent codex resume process लगभग 23 घंटे से चल रहा था।
यह किस workload में हुआ
रिपोर्ट किया गया workflow इस प्रकार था।
- local project में Codex TUI चलाना
- Subagent या collaboration features का उपयोग करने वाला लंबा session चलाना
- मौजूदा parent session को
codex resume <thread-id>से फिर शुरू करना - Resume किए गए process को कई घंटों तक चलते रहने देना
- parent session का depth 1 वाले Subagent बार-बार बनाना
इस workflow में एक दिन में सैकड़ों child JSONL files बनीं, और कई files कुछ ही मिनटों में 400~500MiB तक बढ़ गईं। हालांकि, रिपोर्ट करने वाले ने साफ कहा कि यह न्यूनतम reproduction steps नहीं बल्कि वास्तविक environment में देखा गया reproduction workflow है।
इसलिए फिलहाल सार्वजनिक data से पुष्टि होने वाली मुख्य amplification conditions का संयोजन यह है।
लंबे समय तक चलने वाला parent session
+ codex resume
+ बार-बार Subagent creation
+ Context Compaction
+ Tool output और session events का persistent storage
यह संयोजन सार्वजनिक मामले के data से समर्थित है, लेकिन इन तत्वों में से किसी एक से अकेले हमेशा समस्या होगी, यह अभी साबित नहीं हुआ है।
एक single file के अंदर क्या बढ़ा
एक प्रतिनिधि Subagent लगभग 3 मिनट 19 सेकंड चला, लेकिन उसने 483,714,063 bytes और 353,255 JSONL records लिखे। यह लगभग 1,770 records प्रति सेकंड और लगभग 2.31MiB प्रति सेकंड logging के बराबर है।
इस file में बड़ा हिस्सा लेने वाले records ये थे।
event_msg/token_count 185,461 लगभग 139.3MB
compacted 1,618 लगभग 121.6MB
event_msg/patch_apply_end 36,295 लगभग 110.7MB
event_msg/agent_message 104,653 लगभग 41.6MB
response_item/message 9,947 लगभग 34.4MB
world_state 607 लगभग 18.6MB
turn_context 5,322 लगभग 11.0MB
File का अधिकांश हिस्सा किसी एक विशाल JSON record से नहीं भरा था, बल्कि कम समय में कई तरह के events हजारों से लेकर लाखों बार रिकॉर्ड हुए थे। रिपोर्ट करने वाले ने इसे गंभीर event amplification बताया।
एक दूसरी प्रतिनिधि file लगभग 925.6MB की थी, जिसमें compacted records 175 थे और उन्होंने लगभग 571.6MB लिया, जबकि custom_tool_call_output के 27,848 records ने लगभग 211.7MB लिया। इस file को इस बात के प्रमाण के रूप में पेश किया गया कि सिर्फ event count ही नहीं, बल्कि बड़े Compaction और Tool output payloads का बार-बार सुरक्षित रहना भी size बढ़ने में योगदान देता है।
कारण क्या है
फिलहाल GitHub issue में OpenAI की पुष्टि की हुई Root Cause Analysis प्रकाशित नहीं हुई है। इसलिए नीचे दी गई बातें session files की जांच करने वाले रिपोर्टर के data से निकले अनुमानित कारण हैं।
1. हर Subagent पर event amplification
लगभग 3 मिनट चलने वाले एक Subagent में token_count के 1.8 लाख से अधिक, agent_message के 1 लाख से अधिक, और patch_apply_end के 30 हजार से अधिक records सेव हुए। यह संभावना उठी है कि सामान्य user-visible activity की तुलना में कहीं अधिक events child session writer तक पहुंच रहे हों या बार-बार लिखे जा रहे हों।
2. Compaction history का बार-बार storage
बड़े sessions में compacted records ने file का अधिकांश हिस्सा घेरा। अलग Codex Issue #24948 में भी रिपोर्ट हुआ कि Context Compaction की replacement_history और मूल Tool output बार-बार सेव होने से एक single JSONL 732MB तक और पूरी sessions directory लगभग 91GB तक बढ़ गई। वह issue Codex CLI 0.118.0 और macOS arm64 environment में reproduce हुआ था और 28 मई 2026 को दर्ज किया गया था।
3. Resume के समय पुराने history का duplicate materialization
Windows Codex App के अलग Issue #29531 में रिपोर्ट हुआ कि 2GB से बड़े मौजूदा session को Resume करने पर नई तारीख वाली directory में फिर से 2.3~2.4GB के rollout files बन गए। रिपोर्टर का अनुमान था कि नई files सिर्फ incremental events नहीं लिख रहीं, बल्कि पुराने historical context को copy या replay कर रही हैं।
4. हर Subagent file में parent state या output की duplication
Issue #34061 में एक parent session से बने 2,393 child sessions ने लगभग 731.5GiB जगह घेर ली, और child files में compacted, Tool output और high-frequency events बार-बार देखे गए। इसके आधार पर अनुमान लगाया गया कि parent state या event stream हर Subagent JSONL में duplicate होकर लिखी जा रही है, जो amplification के मुख्य कारणों में से एक हो सकता है। यह फिलहाल सार्वजनिक data पर आधारित निष्कर्ष है, OpenAI की पुष्टि की हुई वजह नहीं।
वर्तमान fix status
सबसे बड़े Subagent disk usage problem को ट्रैक करने वाला Issue #34061, 20 जुलाई 2026 तक Open है, और issue में दिखाई गई reproduced version Codex CLI 0.144.6 है।
Compaction और Tool output समस्या वाला Issue #24948 भी अभी Open है, और Resume duplication वाला Issue #29531 भी Open है।
इसलिए सिर्फ सार्वजनिक issue status के आधार पर यह नहीं कहा जा सकता कि session JSONL growth की पूरी समस्या किसी आधिकारिक release में हल हो चुकी है। यह भी अभी तय नहीं है कि ये सभी issues एक ही code defect से आए हैं या कई persistence problems मिलकर असर कर रही हैं।
जांच कैसे करें
कुल session size देखें:
du -sh ~/.codex/sessions
साल/महीने के हिसाब से size देखें:
du -sh ~/.codex/sessions/*/*
सबसे बड़े JSONL files देखें:
find ~/.codex/sessions \
-type f \
-name '*.jsonl' \
-exec du -h {} + |
sort -hr |
head -30
महीने के हिसाब से file count देखें:
find ~/.codex/sessions/2026/07 \
-type f \
-name '*.jsonl' |
wc -l
Issue #34061 जैसे मामलों में किसी खास महीने में files की संख्या अचानक बढ़ सकती है, या सैकड़ों MB आकार की child session files सैकड़ों से हजारों की संख्या में मिल सकती हैं।
अस्थायी उपाय
जब तक आधिकारिक fix की पुष्टि नहीं होती, तब तक नीचे दिए गए workloads को कम करना एक व्यावहारिक अस्थायी उपाय है।
- एक ही parent session को लंबे समय तक
codex resumeपर चालू न रखें - Resume किए गए लंबे session में बहुत बड़ी संख्या में Subagent न बनाएं
- बड़े command outputs को सीधे context में लौटाने के बजाय file में सेव करें और जरूरत के हिस्से ही देखें
~/.codex/sessionsकी monthly size और बड़े JSONL files को नियमित रूप से जांचें
ये उपाय Issue #24948, #29531, #34061 में देखी गई amplification conditions से बचने के लिए preventive steps हैं; ये आधिकारिक रूप से validated workaround नहीं हैं।
Session files हटाने से disk space तो वापस मिल सकती है, लेकिन फिर उस session को codex resume से दोबारा खोल पाना संभव नहीं भी हो सकता। पहले Codex processes बंद करना, जरूरी sessions का backup लेना, और उसके बाद delete करना अधिक सुरक्षित है।
संबंधित अलग issue: SQLite feedback log write amplification
यह समस्या GeekNews में पहले आई logs_2.sqlite excessive logging problem से storage location और role दोनों में अलग है।
पुरानी समस्या में नीचे दी गई files में global TRACE-level diagnostic और feedback logs लगातार सेव किए जा रहे थे, जिससे SSD write volume बढ़ रहा था।
~/.codex/logs_2.sqlite
~/.codex/logs_2.sqlite-wal
~/.codex/logs_2.sqlite-shm
उस समस्या को 14 जून 2026 को GitHub Issue #28224 के रूप में रिपोर्ट किया गया था, और WebSocket events व noisy logs कम करने वाली PR merge होने के बाद बताया गया कि लगभग 85% logs कम हो गए। कुछ fixes Codex 0.142.0 में शामिल हुए और अतिरिक्त fixes 0.143.0 release के लिए दर्ज किए गए।
इसके विपरीत, इस बार समस्या ~/.codex/sessions/**/rollout-*.jsonl में सेव होने वाले resumable session history से जुड़ी है, और Context Compaction, Resume तथा Subagent session persistence को मुख्य amplification conditions के रूप में देखा गया है। केवल SQLite feedback log fix से session JSONL समस्या हल हो गई, ऐसा कोई प्रमाण नहीं है।
सारांश
Codex CLI का session storage लंबे समय तक Resume किए गए parent sessions में, जहां बार-बार Subagent बनाए जाते हैं, असामान्य रूप से बढ़ सकता है। सबसे बड़े सार्वजनिक मामले में एक parent session से बने 2,393 child sessions ने लगभग 731.5GiB जगह ली, और पूरी sessions directory लगभग 755GiB तक बढ़ गई।
Sessions के अंदर कम समय में लाखों के करीब events रिकॉर्ड होने वाला event amplification, और compacted history तथा Tool output का बार-बार सुरक्षित रहना, दोनों साथ देखे गए। Resume के दौरान पहले से मौजूद multi-GB history के नए rollout files में फिर से बनने का अलग मामला भी रिपोर्ट हुआ।
यह समस्या सबसे बड़े पैमाने पर macOS Codex CLI में रिपोर्ट हुई, लेकिन Windows Codex App में भी मिलती-जुलती session duplication की पुष्टि हुई है, और 20 जुलाई 2026 तक प्रमुख संबंधित issues खुले हैं। आधिकारिक fix की पुष्टि होने तक लंबे Resume sessions और बड़े पैमाने पर Subagent उपयोग को सीमित रखना और ~/.codex/sessions का आकार नियमित रूप से जांचना जरूरी है।
2 टिप्पणियां
मेरे MacBook में भी स्टोरेज कम पड़ रही थी, इसलिए मैंने external SSD तक खरीद ली,
लगता है पहले यही चेक करना पड़ेगा 🥲
इन दिनों MacBook में storage कम होने की notification बार-बार आ रही थी, तो जांचने पर पता चला कि culprit codex cli था। मेरे यहाँ भी इसने अभी तंगी में दर्जनों GB खा रखे हैं, इसलिए सोच रहा हूँ कि पुरानी history हटा दूँ या नहीं। बाकी लोग इससे कैसे निपट रहे हैं?