Có thật. Công cụ lập trình OpenAI Codex CLI có một lỗi ghi log khiến nó liên tục ghi dữ liệu chẩn đoán xuống một database SQLite trên ổ đĩa — theo báo cáo trên GitHub là ~37 TB chỉ trong 21 ngày, tương đương ~640 TB/năm. Một SSD tiêu dùng 1TB thường chỉ chịu được khoảng 600 TBW (Total Bytes Written), nghĩa là lỗi này có thể "đốt" hết tuổi thọ ghi được bảo hành của ổ trong chưa đầy một năm. Tin này là sự thật, nhưng đã có bản vá giảm ~85% lượng log — chi tiết và cách khắc phục ở dưới.
Tóm tắt nhanh
- Cái gì: OpenAI Codex CLI (công cụ agent lập trình dòng lệnh) ghi log mức TRACE quá mức xuống file SQLite cục bộ.
- Ai phát hiện: Lập trình viên @1996fanrui trên GitHub, mở issue #28224 ngày 14/06/2026.
- Mức độ: ~37 TB ghi trong 21 ngày ≈ ~640 TB/năm; SSD 1TB (~600 TBW) có thể cạn tuổi thọ trong < 1 năm.
- File liên quan:
~/.codex/logs_2.sqlite(cùng-wal,-shm). - Trạng thái: Issue đã đóng 22/06/2026 — 2 PR (#29432, #29457) được merge, giảm ~85% lượng log. Hãy cập nhật Codex bản mới nhất.
Chuyện gì đã xảy ra?
Ngày 14/06/2026, lập trình viên @1996fanrui để ý thấy ổ đĩa hoạt động bất thường và lần ra thủ phạm: OpenAI Codex CLI liên tục ghi vào một database SQLite cục bộ tại ~/.codex/logs_2.sqlite. Anh mở issue #28224 trên repo openai/codex.
Theo số liệu trong issue, sau 21 ngày máy chạy liên tục, ổ chính đã phải "nuốt" khoảng 37 TB dữ liệu ghi — quy đổi ra khoảng 640 TB mỗi năm. Điều đáng nói là phần lớn dữ liệu này vô dụng với người dùng thường: log nội bộ, payload thô của WebSocket, và các sự kiện hệ thống lặt vặt.
Vì sao lại ghi nhiều đến vậy?
Gốc rễ là cấu hình log để ở mức TRACE — mức "ồn ào" nhất — làm mặc định cho toàn bộ sink SQLite (Targets::new().with_default(Level::TRACE)). Phân tích trong issue cho thấy log mức TRACE chiếm tới 70,7% dung lượng được lưu, với nguồn áp đảo là các sự kiện vặt như theo dõi file (riêng sự kiện mở ld.so.cache đã xuất hiện 128.764 lần) và nội bộ thư viện WebSocket.
Tệ hơn là hiện tượng "khuếch đại ghi" (write amplification): database không chỉ phình to mà còn liên tục chèn–xóa hàng chục nghìn dòng mỗi phút. Trong một mẫu 15 giây, có ~36.211 dòng được chèn trong khi số dòng giữ lại gần như không đổi; bộ đếm tự tăng đã vượt 5,5 tỷ ID dù chỉ giữ ~506.149 dòng — chênh lệch khoảng 10.000 lần. Lượng ghi vật lý xuống ổ vì thế lớn hơn nhiều so với kích thước file.
Một điểm khó chịu: lỗi này bỏ qua biến môi trường RUST_LOG tiêu chuẩn, nên người dùng không có cách "vặn nhỏ" log theo cách thông thường.
SSD bị ảnh hưởng tới mức nào?
SSD có giới hạn ghi (đo bằng TBW — Total Bytes Written). Một SSD tiêu dùng 1TB phổ biến được bảo hành quanh mức ~600 TBW. Với tốc độ ~640 TB/năm, lỗi này một mình nó có thể tiêu hết hạn mức ghi bảo hành của ổ trong chưa đầy 12 tháng — đúng như tiêu đề nhiều báo giật.
Ai bị ảnh hưởng nặng nhất: người để Codex chạy nền liên tục, hoặc bật trên máy/laptop dùng cả ngày. Lưu ý đây là rủi ro tích lũy theo thời gian, không phải hỏng ngay; nhưng để lâu không xử lý thì hậu quả là thật.
Đã có bản vá chưa? Cách tự kiểm tra & khắc phục
Đã có. Issue #28224 được đóng ngày 22/06/2026: hai pull request #29432 ("ngừng ghi mọi sự kiện WebSocket của Responses") và #29457 ("lọc bỏ các nguồn log ồn") đã được merge, giảm khoảng 85% lượng log. Việc cần làm trước tiên là cập nhật Codex CLI lên bản mới nhất.
Nếu chưa cập nhật được ngay, có thể giảm thiểu (theo cộng đồng — tham khảo, hãy tự cân nhắc rủi ro):
- Kiểm tra mức độ: xem kích thước và biến động của
~/.codex/logs_2.sqlite; theo dõi chỉ số ghi của ổ bằng công cụ S.M.A.R.T. (vdsmartctl). - Linux/macOS: trỏ (symlink)
~/.codex/logs_2.sqlitesang/tmp/để ghi vào RAM thay vì SSD — file này không chứa dữ liệu hội thoại nên mất khi khởi động lại cũng không sao. - Windows: chưa có cách lách đơn giản tương đương — ưu tiên cập nhật bản đã vá.
- Tắt Codex khi không dùng thay vì để chạy nền cả ngày.
Lưu ý: các bước can thiệp file/symlink là thao tác kỹ thuật; nếu không chắc, hãy chỉ cập nhật bản chính thức đã vá.
Góc nhìn cho doanh nghiệp
Sự việc Codex là lời nhắc: công cụ AI/agent chạy trên máy của bạn vẫn có thể âm thầm gây hại nếu thiếu giám sát. Vài điều rút ra cho doanh nghiệp khi đưa AI vào vận hành:
- Giám sát tài nguyên (I/O, disk, RAM) cho mọi tiến trình AI/agent — đặt cảnh báo khi ghi đĩa tăng bất thường.
- Kiểm soát cấu hình & log: biết rõ phần mềm đang ghi gì, ở đâu, mức nào — tránh để mặc định "ẩn" gây hao mòn phần cứng.
- Chủ động về hạ tầng: khi vận hành AI tại chỗ, bạn nắm toàn quyền cấu hình, log và tài nguyên — dễ phát hiện và chặn các hành vi bất thường như thế này.
Đây cũng là triết lý của nền tảng AI riêng tư nội bộ Namtech: chạy trên hạ tầng của chính doanh nghiệp, minh bạch về cấu hình và dữ liệu — không bị "hộp đen" của bên thứ ba quyết định thay.
Câu hỏi thường gặp
Codex ở đây là gì — có phải model Codex cũ năm 2021 không?
Không. Đây là OpenAI Codex CLI — công cụ agent lập trình dòng lệnh (mã nguồn mở, repo openai/codex), không phải model API "Codex" cũ. Lỗi nằm ở phần ghi log của công cụ này.
Lỗi này có làm hỏng SSD ngay lập tức không?
Không tức thì. Đây là hao mòn tích lũy: ghi ~640 TB/năm có thể tiêu hết hạn mức ghi bảo hành (~600 TBW với SSD 1TB) trong dưới một năm nếu để chạy liên tục mà không xử lý.
Tôi nên làm gì ngay bây giờ?
Cập nhật Codex CLI lên bản mới nhất (đã giảm ~85% log). Có thể kiểm tra kích thước ~/.codex/logs_2.sqlite và theo dõi chỉ số ghi ổ qua S.M.A.R.T. để yên tâm.
Số liệu 640 TB/năm có chính xác không?
Đây là con số ngoại suy từ ~37 TB đo được trong 21 ngày, do người báo lỗi nêu trong issue #28224 và được nhiều báo công nghệ dẫn lại. Là ước tính tham khảo, mức thực tế tùy cách sử dụng.
Đưa AI vào vận hành — có kiểm soát
Namtech triển khai nền tảng AI riêng tư nội bộ chạy 100% trên hạ tầng của bạn: minh bạch cấu hình, log và tài nguyên, dữ liệu không rời tổ chức.
Đặt lịch tư vấn miễn phíLưu ý: Bài viết tổng hợp từ nguồn công khai tại 23/06/2026 (GitHub issue #28224 và báo công nghệ); số liệu là ước tính, tình hình có thể thay đổi. Thông tin tham khảo, không phải tư vấn kỹ thuật chính thức.