Vấn đề log phiên Subagent của Codex CLI tăng lên hàng trăm GB và làm cạn dung lượng đĩa

Đã có báo cáo rằng khi Codex CLI liên tục tạo Subagent trong một phiên dài đã được Resume, các tệp phiên JSONL dưới ~/.codex/sessions tăng bất thường
Trong trường hợp công khai, 2.393 tệp phiên Subagent được tạo từ một phiên cha đã Resume, và các tệp này chiếm khoảng 731,5GiB
Tổng dữ liệu phiên Codex tăng lên khoảng 755GiB, khiến mức sử dụng của volume APFS 1,8TiB đạt 99~100%
Ngay cả trong các phiên Subagent ngắn cũng ghi lại hàng trăm nghìn event; ở các phiên khác, lịch sử compacted và Tool output được lưu lặp lại ở mức hàng trăm MB
Vấn đề cũng được xác nhận trong Codex CLI 0.144.6 ở trường hợp mới nhất, và issue GitHub liên quan vẫn đang mở tính đến ngày 20/7/2026

Triệu chứng của vấn đề

Codex CLI lưu hội thoại và lịch sử thực thi ở định dạng JSONL tại đường dẫn sau để có thể mở lại phiên.

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

Trong trường hợp được đăng ký ngày 18/7/2026, toàn bộ ~/.codex dùng khoảng 760GiB, trong đó ~/.codex/sessions dùng khoảng 755GiB, và riêng các phiên tháng 7 chiếm khoảng 734GiB.

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

Dữ liệu này không phải cache mà là lịch sử phiên dùng cho codex resume, nên nếu xóa tệp thì có khả năng không thể mở lại các phiên trước đó. Tại thời điểm báo cáo, nhiều tiến trình Codex vẫn đang giữ mở các tệp JSONL đó.

Tăng nhanh đến mức nào

Trong thư mục tháng 7 của trường hợp này có khoảng 2.931 tệp phiên, trong đó 797 tệp vượt quá 400MiB mỗi tệp. Thống kê cho thấy ngày 11/7 đã tạo khoảng 109,1GiB dữ liệu phiên trong một ngày, và ngày 12/7 khoảng 149,2GiB.

Ngày       Tệp phiên     Trên 400MiB     Dung lượng ước tính  
10/7          50              0              2,8GiB  
11/7         473              0            109,1GiB  
12/7         506              0            149,2GiB  
15/7         340            265            108,6GiB  
16/7         355            263            109,0GiB  
17/7         300            189             81,7GiB

Phần lớn dung lượng liên quan đến một phiên cha đã Resume. Phiên cha này tạo 2.393 tệp JSONL Subagent, với tổng kích thước logic khoảng 731,5GiB. Tại thời điểm điều tra, tiến trình codex resume cha đã chạy khoảng 23 giờ.

Xảy ra với workload nào

Workflow được báo cáo như sau.

Chạy Codex TUI trong dự án local
Làm việc trong phiên dài sử dụng Subagent hoặc tính năng cộng tác
Tiếp tục phiên cha hiện có bằng codex resume <thread-id>
Giữ tiến trình đã Resume chạy trong nhiều giờ
Phiên cha liên tục tạo Subagent ở depth 1

Trong workflow này, mỗi ngày tạo ra hàng trăm tệp JSONL con, và nhiều tệp tăng lên 400~500MiB chỉ trong vài phút. Tuy nhiên, người báo cáo nói rõ đây không phải là quy trình tái hiện tối thiểu, mà là workflow tái hiện được quan sát trong môi trường thực tế.

Do đó, các điều kiện khuếch đại chính hiện được xác nhận từ tài liệu công khai là tổ hợp sau.

Phiên cha chạy trong thời gian dài  
+ codex resume  
+ tạo Subagent lặp lại  
+ Context Compaction  
+ lưu vĩnh viễn Tool output và event phiên

Tổ hợp này được xác nhận bằng dữ liệu của trường hợp công khai, nhưng chưa chứng minh rằng chỉ riêng một yếu tố bất kỳ trong số đó luôn gây ra vấn đề.

Bên trong một tệp đơn lẻ, thứ gì đã tăng

Một Subagent tiêu biểu chỉ chạy khoảng 3 phút 19 giây, nhưng đã ghi 483.714.063 byte và 353.255 bản ghi JSONL. Tương đương khoảng 1.770 bản ghi mỗi giây và khoảng 2,31MiB dữ liệu ghi mỗi giây.

Các bản ghi chiếm tỷ trọng lớn trong tệp này như sau.

event_msg/token_count        185.461 mục    khoảng 139,3MB  
compacted                      1.618 mục    khoảng 121,6MB  
event_msg/patch_apply_end     36.295 mục    khoảng 110,7MB  
event_msg/agent_message      104.653 mục     khoảng 41,6MB  
response_item/message          9.947 mục     khoảng 34,4MB  
world_state                      607 mục     khoảng 18,6MB  
turn_context                   5.322 mục     khoảng 11,0MB

Không phải một bản ghi JSON khổng lồ chiếm phần lớn tệp, mà là nhiều loại event được ghi hàng nghìn đến hàng trăm nghìn lần trong thời gian chạy ngắn. Người báo cáo phân tích đây là tình trạng event amplification nghiêm trọng.

Một tệp tiêu biểu khác có kích thước khoảng 925,6MB; 175 bản ghi compacted chiếm khoảng 571,6MB, và 27.848 custom_tool_call_output chiếm khoảng 211,7MB. Tệp này được đưa ra làm bằng chứng rằng không chỉ số lượng event, mà cả việc lưu lặp lại các payload Compaction và Tool output lớn cũng góp phần làm tăng dung lượng.

Nguyên nhân phát sinh là gì

Hiện issue GitHub chưa có Root Cause Analysis được OpenAI xác nhận. Vì vậy nội dung sau là nguyên nhân phỏng đoán rút ra từ dữ liệu người báo cáo điều tra trong các tệp phiên.

1. Khuếch đại event theo từng Subagent

Một Subagent chạy khoảng 3 phút đã lưu hơn 180 nghìn token_count, hơn 100 nghìn agent_message, và hơn 30 nghìn patch_apply_end. Có khả năng nhiều event hơn hoạt động người dùng thấy được thông thường đã được chuyển tới writer của phiên con hoặc bị ghi lặp lại.

2. Lưu lặp lại lịch sử Compaction

Trong các phiên lớn, bản ghi compacted chiếm phần lớn tệp. Một Codex Issue riêng #24948 cũng báo cáo trường hợp replacement_history của Context Compaction và Tool output gốc bị lưu lặp lại, khiến một JSONL đơn lẻ tăng lên 732MB và toàn bộ thư mục sessions lên khoảng 91GB. Issue này được tái hiện trên Codex CLI 0.118.0 và môi trường macOS arm64, được đăng ký ngày 28/5/2026.

3. Materialization trùng lặp lịch sử cũ khi Resume

Trong Issue riêng #29531 của Windows Codex App, có báo cáo rằng khi Resume một phiên hiện có đã lớn hơn 2GB, các tệp rollout mới kích thước 2,3~2,4GB lại được tạo trong thư mục ngày mới. Người báo cáo cho rằng tệp mới không chỉ ghi event gia tăng, mà đang sao chép hoặc replay historical context hiện có.

4. Trùng lặp trạng thái hoặc output của phiên cha theo từng tệp Subagent

Trong Issue #34061, 2.393 phiên con được tạo từ một phiên cha chiếm khoảng 731,5GiB, và trong các tệp con liên tục quan sát thấy compacted, Tool output cùng event tần suất cao. Từ đó suy đoán rằng trạng thái cha hoặc event stream bị ghi trùng lặp vào JSONL của từng Subagent là một trong các yếu tố khuếch đại cốt lõi. Đây là suy luận dựa trên dữ liệu công khai hiện có, không phải nguyên nhân đã được OpenAI xác nhận.

Tình trạng sửa lỗi hiện tại

Issue #34061 xử lý vấn đề Subagent dùng đĩa lớn nhất đang ở trạng thái Open tính đến ngày 20/7/2026, và phiên bản tái hiện hiển thị trong issue là Codex CLI 0.144.6.

Issue #24948 xử lý vấn đề Compaction và Tool output cũng đang Open, và Issue #29531 xử lý vấn đề trùng lặp khi Resume cũng đang Open.

Do đó, nếu chỉ dựa trên trạng thái các issue công khai hiện tại, chưa xác nhận được bản phát hành chính thức nào có thể xem là đã giải quyết toàn bộ vấn đề tăng JSONL phiên. Cũng chưa xác định liệu từng issue bắt nguồn từ cùng một lỗi code hay do nhiều vấn đề persistence kết hợp.

Cách kiểm tra

Kiểm tra tổng dung lượng phiên:

du -sh ~/.codex/sessions

Kiểm tra dung lượng theo năm/tháng:

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

Kiểm tra các tệp JSONL lớn nhất:

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

Kiểm tra số lượng tệp theo tháng:

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

Trong các trường hợp tương tự Issue #34061, số tệp của một tháng cụ thể có thể tăng vọt, hoặc có thể tìm thấy hàng trăm đến hàng nghìn tệp phiên con kích thước hàng trăm MB.

Biện pháp tạm thời

Trước khi xác nhận bản sửa chính thức, việc giảm các workload sau là biện pháp tạm thời hợp lý.

Không duy trì một phiên cha bằng codex resume trong thời gian dài
Không tạo hàng loạt Subagent trong phiên dài đã Resume
Không trả nguyên output lệnh lớn vào context; thay vào đó lưu thành tệp rồi chỉ xem phần cần thiết
Định kỳ kiểm tra dung lượng theo tháng của ~/.codex/sessions và các tệp JSONL lớn

Đây là các biện pháp phòng tránh các điều kiện khuếch đại được quan sát trong Issue #24948, #29531, #34061, không phải workaround đã được xác minh chính thức.

Xóa tệp phiên có thể thu hồi dung lượng đĩa, nhưng có khả năng không thể mở lại phiên đó bằng codex resume. An toàn hơn là kết thúc các tiến trình Codex trước, sao lưu các phiên cần thiết rồi mới xóa.

Issue riêng liên quan: Khuếch đại ghi log phản hồi SQLite

Vấn đề này khác với logs_2.sqlite ghi log quá mức từng được giới thiệu trên GeekNews về vị trí lưu trữ và vai trò.

Issue trước đó là vấn đề liên tục lưu diagnostic và feedback log ở mức TRACE toàn cục vào các tệp sau, làm khuếch đại lượng ghi SSD.

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

Vấn đề đó được báo cáo ngày 14/6/2026 dưới dạng GitHub Issue #28224, và PR giảm WebSocket event cùng log nhiễu đã được merge, được tổng kết là giảm khoảng 85% log. Một số bản sửa được đưa vào Codex 0.142.0, và các bản sửa bổ sung được ghi nhận là mục tiêu của bản phát hành 0.143.0.

Ngược lại, vấn đề lần này nhắm tới ~/.codex/sessions/**/rollout-*.jsonl, nơi lưu lịch sử phiên có thể Resume, và Context Compaction, Resume cùng Subagent session persistence được quan sát là các điều kiện khuếch đại chính. Không có căn cứ cho thấy chỉ sửa SQLite feedback log là giải quyết được vấn đề session JSONL.

Tóm tắt

Kho lưu phiên của Codex CLI có thể tăng bất thường trong workload mà một phiên cha đã Resume lâu dài liên tục tạo Subagent. Trong trường hợp công khai lớn nhất, 2.393 phiên con được tạo từ một phiên cha chiếm khoảng 731,5GiB, và toàn bộ thư mục sessions tăng lên khoảng 755GiB.

Bên trong phiên, quan sát thấy đồng thời event amplification, trong đó hàng trăm nghìn event được ghi trong thời gian ngắn, và việc lưu lặp lại compacted history cùng Tool output. Cũng có báo cáo riêng về việc history nhiều GB hiện có được tạo lại trong tệp rollout mới khi Resume.

Vấn đề được báo cáo ở quy mô lớn nhất trên macOS Codex CLI, nhưng session duplication tương tự cũng được xác nhận trong Windows Codex App; tính đến ngày 20/7/2026, các issue liên quan chính vẫn đang mở. Cho đến khi xác nhận có bản sửa chính thức, cần hạn chế Resume dài hạn và dùng nhiều Subagent, đồng thời định kỳ kiểm tra kích thước của ~/.codex/sessions.