ปัญหา Session log ของ Subagent ใน Codex CLI โตได้ถึงหลายร้อย GB จนทำให้ดิสก์เต็ม

มีรายงานปัญหาที่ไฟล์ session แบบ JSONL ใต้ ~/.codex/sessions โตผิดปกติ เมื่อ Codex CLI สร้าง Subagent ซ้ำ ๆ ใน long session ที่ถูก Resume
ในกรณีที่เปิดเผยสู่สาธารณะ มีการสร้างไฟล์ session ของ Subagent จำนวน 2,393 ไฟล์จาก parent session ที่ถูก Resume เพียงตัวเดียว และไฟล์เหล่านี้ใช้พื้นที่ราว 731.5GiB
ข้อมูล session ของ Codex ทั้งหมดเพิ่มขึ้นถึงราว 755GiB และการใช้งานบน APFS volume ขนาด 1.8TiB แตะ 99~100%
แม้ใน session ของ Subagent ที่สั้นมาก ก็ยังมีการบันทึก event หลายแสนรายการ และในอีกบาง session มีการเก็บประวัติ compacted กับ Tool output ซ้ำ ๆ เป็นหน่วยหลายร้อย MB
ปัญหานี้ยังยืนยันได้ใน Codex CLI 0.144.6 จากกรณีล่าสุด และ GitHub issue ที่เกี่ยวข้องยังคงเปิดอยู่ ณ วันที่ 20 กรกฎาคม 2026

อาการของปัญหา

Codex CLI จะบันทึกบทสนทนาและประวัติการทำงานในรูปแบบ JSONL ที่พาธต่อไปนี้ เพื่อให้สามารถเปิด session เดิมได้อีกครั้ง

~/.codex/sessions/YYYY/MM/DD/rollout-*.jsonl

ในกรณีที่ถูกรายงานเมื่อ 18 กรกฎาคม 2026 พบว่า ~/.codex ทั้งหมดใช้พื้นที่ราว 760GiB โดยในนั้น ~/.codex/sessions ใช้ราว 755GiB และเฉพาะ session ของเดือนกรกฎาคมใช้ราว 734GiB

760G  ~/.codex  
755G  ~/.codex/sessions  
734G  ~/.codex/sessions/2026/07

ข้อมูลนี้ไม่ใช่ cache แต่เป็นประวัติ session ที่ใช้กับ codex resume ดังนั้นหากลบไฟล์ออก ก็อาจไม่สามารถเปิด session เก่าได้อีก ในเวลาที่มีการรายงาน ก็ยังมีหลาย Codex process ที่เปิดไฟล์ JSONL เหล่านี้ค้างไว้ต่อเนื่อง

เพิ่มขึ้นเร็วแค่ไหน

ในกรณีดังกล่าว ไดเรกทอรีของเดือนกรกฎาคมมีไฟล์ session ราว 2,931 ไฟล์ และในนั้น 797 ไฟล์มีขนาดเกิน 400MiB ต่อไฟล์ มีการคำนวณว่าภายในวันเดียว วันที่ 11 กรกฎาคม มีการสร้างข้อมูล session ราว 109.1GiB และวันที่ 12 กรกฎาคม ราว 149.2GiB

วันที่        ไฟล์ session     เกิน 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

พื้นที่ส่วนใหญ่เชื่อมโยงกับ parent session ที่ถูก Resume เพียงตัวเดียว โดย parent session นี้สร้างไฟล์ Subagent JSONL จำนวน 2,393 ไฟล์ และมีขนาดเชิงตรรกะรวมราว 731.5GiB ขณะตรวจสอบ parent codex resume process ทำงานต่อเนื่องมาราว 23 ชั่วโมง

เกิดขึ้นกับ workload แบบไหน

workflow ที่ถูกรายงานมีดังนี้

รัน Codex TUI บนโปรเจกต์ในเครื่อง
ทำงานใน long session ที่ใช้ Subagent หรือฟีเจอร์ collaboration
เปิด parent session เดิมอีกครั้งด้วย codex resume <thread-id>
ปล่อยให้ process ที่ Resume ไว้ทำงานต่อเนื่องหลายชั่วโมง
parent session สร้าง Subagent ระดับ depth 1 ซ้ำ ๆ

ใน workflow นี้ มีการสร้างไฟล์ JSONL ของลูกวันละหลายร้อยไฟล์ และหลายไฟล์โตถึง 400~500MiB ภายในไม่กี่นาที อย่างไรก็ตาม ผู้รายงานระบุชัดว่านี่ไม่ใช่ขั้นตอน reproduce ขั้นต่ำ แต่เป็น workflow ที่สังเกตพบซ้ำได้ในสภาพแวดล้อมจริง

ดังนั้น เงื่อนไขหลักที่ดูเหมือนเป็นตัวเร่งการขยายขนาดจากข้อมูลสาธารณะในตอนนี้ คือการรวมกันของสิ่งต่อไปนี้

parent session ที่รันยาวนาน  
+ codex resume  
+ การสร้าง Subagent ซ้ำ ๆ  
+ Context Compaction  
+ การเก็บ Tool output และ session event แบบถาวร

ชุดเงื่อนไขนี้ยืนยันได้จากข้อมูลของกรณีที่เปิดเผยสู่สาธารณะ แต่ยังไม่พิสูจน์ว่าเพียงองค์ประกอบใดองค์ประกอบหนึ่งจะทำให้เกิดปัญหาเสมอ

ภายในไฟล์เดี่ยวมีอะไรที่เพิ่มขึ้นบ้าง

Subagent ตัวอย่างหนึ่งทำงานเพียงราว 3 นาที 19 วินาที แต่บันทึกข้อมูล 483,714,063 ไบต์และมี JSONL record 353,255 รายการ คิดเป็นราว 1,770 record ต่อวินาที และอัตราการบันทึกราว 2.31MiB ต่อวินาที

record ที่กินสัดส่วนมากในไฟล์นี้มีดังนี้

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

ไม่ใช่ว่ามี JSON record ขนาดมหึมาเพียงรายการเดียวที่กินพื้นที่เกือบทั้งหมดของไฟล์ แต่เป็นการบันทึก event หลายประเภทตั้งแต่หลักพันถึงหลักแสนครั้งภายในช่วงเวลาสั้น ๆ ผู้รายงานวิเคราะห์ว่านี่คือ event amplification ที่รุนแรง

อีกไฟล์ตัวอย่างหนึ่งมีขนาดราว 925.6MB โดยมี compacted record 175 รายการกินพื้นที่ราว 571.6MB และ custom_tool_call_output 27,848 รายการกินพื้นที่ราว 211.7MB ไฟล์นี้ถูกยกมาเป็นหลักฐานว่า ไม่ใช่แค่จำนวน event เท่านั้น แต่การเก็บ Compaction และ Tool output payload ขนาดใหญ่ซ้ำ ๆ ก็มีส่วนทำให้ขนาดพุ่งขึ้นเช่นกัน

สาเหตุคืออะไร

ปัจจุบันใน GitHub issue ยังไม่มี Root Cause Analysis ที่ OpenAI ยืนยันอย่างเป็นทางการ ดังนั้นเนื้อหาต่อไปนี้จึงเป็นสาเหตุที่คาดการณ์จากข้อมูลของผู้รายงานซึ่งตรวจสอบไฟล์ session ด้วยตนเอง

1. การขยาย event ต่อ Subagent

Subagent ตัวหนึ่งที่ทำงานราว 3 นาที มีการเก็บ token_count มากกว่า 180,000 รายการ, agent_message มากกว่า 100,000 รายการ และ patch_apply_end มากกว่า 30,000 รายการ จึงมีการตั้งข้อสังเกตว่าอาจมี event มากเกินกว่ากิจกรรมที่ผู้ใช้มองเห็นตามปกติถูกส่งต่อหรือถูกบันทึกซ้ำไปยัง child session writer

2. การบันทึกประวัติ Compaction ซ้ำ ๆ

ใน session ขนาดใหญ่ compacted record กินพื้นที่ส่วนใหญ่ของไฟล์ ใน Codex Issue #24948 แยกต่างหาก ก็มีรายงานว่าการเก็บ replacement_history ของ Context Compaction และ Tool output ต้นฉบับซ้ำ ๆ ทำให้ JSONL ไฟล์เดียวโตถึง 732MB และทั้งไดเรกทอรี sessions โตได้ถึงราว 91GB issue นี้ reproduce ได้บน Codex CLI 0.118.0 กับ macOS arm64 และถูกเปิดเมื่อ 28 พฤษภาคม 2026

3. การ materialize ประวัติเดิมซ้ำตอน Resume

ใน Issue #29531 ของ Windows Codex App มีรายงานแยกว่าหลัง Resume session เดิมที่โตเกิน 2GB แล้ว ไฟล์ rollout ขนาด 2.3~2.4GB ถูกสร้างขึ้นใหม่อีกครั้งในไดเรกทอรีของวันใหม่ ผู้รายงานคาดว่าไฟล์ใหม่ไม่ได้บันทึกเฉพาะ event แบบ incremental แต่คัดลอกหรือ replay historical context เดิมด้วย

4. การบันทึกสถานะหรือ output ของ parent ซ้ำในแต่ละไฟล์ Subagent

ใน Issue #34061 มี child session 2,393 รายการที่สร้างจาก parent session เดียวและกินพื้นที่ราว 731.5GiB พร้อมพบ compacted, Tool output และ event ความถี่สูงซ้ำ ๆ ในไฟล์ลูก จากข้อมูลนี้จึงมีการคาดการณ์ว่าการบันทึกสถานะของ parent หรือ event stream ซ้ำลงใน JSONL ของแต่ละ Subagent น่าจะเป็นหนึ่งในตัวเร่งหลักของการขยายขนาด อย่างไรก็ตาม นี่ยังเป็นเพียงข้อสรุปจากข้อมูลสาธารณะ ไม่ใช่สาเหตุที่ OpenAI ยืนยันแล้ว

สถานะการแก้ไขในตอนนี้

Issue #34061 ซึ่งว่าด้วยปัญหาการใช้ดิสก์มหาศาลจาก Subagent ยังอยู่ในสถานะ Open ณ วันที่ 20 กรกฎาคม 2026 และเวอร์ชันที่ระบุว่าสามารถ reproduce ได้คือ Codex CLI 0.144.6

Issue #24948 ที่เกี่ยวกับ Compaction และ Tool output ก็ยัง Open เช่นกัน และ Issue #29531 ที่เกี่ยวกับการซ้ำซ้อนตอน Resume ก็ยัง Open

ดังนั้น หากอิงเฉพาะสถานะ issue ที่เปิดเผยอยู่ในตอนนี้ ก็ยังไม่พบ release ทางการที่ยืนยันได้ว่าปัญหาการเพิ่มขนาดของ session JSONL ได้รับการแก้ไขครบแล้ว และยังไม่แน่ชัดว่าแต่ละ issue มาจากบั๊กจุดเดียวกันหรือเป็นปัญหา persistence หลายส่วนที่ซ้อนกัน

วิธีตรวจสอบ

ตรวจสอบขนาด session ทั้งหมด:

du -sh ~/.codex/sessions

ตรวจสอบขนาดแยกตามปี/เดือน:

du -sh ~/.codex/sessions/*/*

ดูไฟล์ JSONL ที่ใหญ่ที่สุด:

find ~/.codex/sessions \  
  -type f \  
  -name '*.jsonl' \  
  -exec du -h {} + |  
sort -hr |  
head -30

ตรวจสอบจำนวนไฟล์รายเดือน:

find ~/.codex/sessions/2026/07 \  
  -type f \  
  -name '*.jsonl' |  
wc -l

ในกรณีที่คล้ายกับ Issue #34061 จำนวนไฟล์ของบางเดือนอาจพุ่งขึ้นอย่างรวดเร็ว หรืออาจพบไฟล์ child session ขนาดหลายร้อย MB จำนวนหลายร้อยถึงหลายพันไฟล์

แนวทางรับมือชั่วคราว

ก่อนจะมีการยืนยันการแก้ไขอย่างเป็นทางการ การลด workload ต่อไปนี้น่าจะเป็นมาตรการชั่วคราวที่สมเหตุสมผล

อย่าคง parent session เดียวด้วย codex resume เป็นเวลานาน
หลีกเลี่ยงการสร้าง Subagent จำนวนมากใน long session ที่ถูก Resume
อย่าส่งผลลัพธ์คำสั่งขนาดใหญ่กลับเข้า context ตรง ๆ แต่ให้บันทึกลงไฟล์แล้วค่อยดึงมาเฉพาะส่วนที่จำเป็น
ตรวจสอบขนาดรายเดือนของ ~/.codex/sessions และไฟล์ JSONL ขนาดใหญ่เป็นระยะ

สิ่งเหล่านี้เป็นมาตรการป้องกันเพื่อหลีกเลี่ยงเงื่อนไขที่ทำให้เกิดการขยายขนาดตามที่พบใน Issue #24948, #29531, #34061 และยังไม่ใช่ workaround ที่ผ่านการยืนยันอย่างเป็นทางการ

การลบไฟล์ session สามารถคืนพื้นที่ดิสก์ได้ แต่ก็อาจทำให้ไม่สามารถเปิด session นั้นใหม่ด้วย codex resume ได้เช่นกัน จึงปลอดภัยกว่าหากปิด Codex process ก่อน สำรอง session ที่จำเป็นไว้ แล้วค่อยลบ

อีก issue ที่เกี่ยวข้อง: การขยายการเขียนของ SQLite feedback log

ปัญหานี้ต่างจากกรณี logs_2.sqlite logging มากเกินไป ที่เคยถูกนำเสนอใน GeekNews ทั้งในด้านตำแหน่งจัดเก็บและหน้าที่การใช้งาน

issue เดิมคือการบันทึก diagnostic และ feedback log ระดับ TRACE แบบต่อเนื่องลงในไฟล์ต่อไปนี้ จนทำให้ปริมาณการเขียนลง SSD สูงผิดปกติ

~/.codex/logs_2.sqlite  
~/.codex/logs_2.sqlite-wal  
~/.codex/logs_2.sqlite-shm

ปัญหานี้ถูกรายงานใน GitHub Issue #28224 เมื่อ 14 มิถุนายน 2026 และมีการ merge PR ที่ลด WebSocket event และ noise log จนสรุปได้ว่าปริมาณ log ลดลงราว 85% การแก้ไขบางส่วนรวมอยู่ใน Codex 0.142.0 และการแก้เพิ่มเติมถูกระบุไว้สำหรับ release 0.143.0

แต่ปัญหาในครั้งนี้เกี่ยวกับ ~/.codex/sessions/**/rollout-*.jsonl ซึ่งใช้เก็บประวัติ session ที่สามารถ Resume ได้ โดยมี Context Compaction, Resume และ Subagent session persistence เป็นเงื่อนไขหลักที่สังเกตได้ว่าเร่งการขยายขนาด และยังไม่มีหลักฐานว่าการแก้ SQLite feedback log เพียงอย่างเดียวจะแก้ปัญหา session JSONL นี้ได้

สรุป

พื้นที่เก็บ session ของ Codex CLI อาจโตผิดปกติใน workload ที่ parent session ถูก Resume เป็นเวลานานและสร้าง Subagent ซ้ำ ๆ ในกรณีสาธารณะที่ใหญ่ที่สุด child session 2,393 รายการที่สร้างจาก parent session เดียวกินพื้นที่ราว 731.5GiB และทั้งไดเรกทอรี sessions โตถึงราว 755GiB

ภายใน session มีทั้ง event amplification ที่ทำให้เกิดการบันทึก event หลายแสนครั้งในช่วงเวลาสั้น ๆ และการเก็บประวัติ compacted กับ Tool output ซ้ำ ๆ ไปพร้อมกัน นอกจากนี้ยังมีรายงานอีกกรณีว่าระหว่าง Resume ประวัติเดิมขนาดหลาย GB ถูกสร้างซ้ำใน rollout ไฟล์ใหม่

แม้กรณีที่ใหญ่ที่สุดจะถูกรายงานบน macOS Codex CLI แต่ก็มีการยืนยัน session duplication ลักษณะคล้ายกันใน Windows Codex App ด้วย และ ณ วันที่ 20 กรกฎาคม 2026 issue หลักที่เกี่ยวข้องยังคงเปิดอยู่ ก่อนจะมีการยืนยันการแก้ไขอย่างเป็นทางการ จึงควรจำกัดการใช้ long Resume และ Subagent จำนวนมาก พร้อมตรวจสอบขนาดของ ~/.codex/sessions เป็นระยะ