Codex Desktop "ăn" sạch ổ cứng máy Mac: lỗi kéo dài nhiều tháng, có máy mất hơn 300 GB

Một báo cáo lỗi (issue) trên GitHub của OpenAI đang thu hút sự chú ý của cộng đồng phát triển: ứng dụng Codex Desktop trên macOS âm thầm sinh ra hàng triệu file báo cáo sự cố, có trường hợp chiếm tới 323 GB ổ cứng mà người dùng không hề hay biết. Điều đáng nói là lỗi này đã được ghi nhận từ tháng 6/2026 nhưng đến nay vẫn tái diễn trên nhiều phiên bản mới.

Chuyện gì đang xảy ra?

Theo mô tả trong issue #25921, ứng dụng Codex Desktop liên tục tạo ra các cặp file .dmp và _sidecar.json trong thư mục:

~/Library/Application Support/com.openai.codex/web/Crashpad/pending

Đây là thư mục mà Crashpad — thành phần xử lý báo cáo sự cố của Chromium/Electron — dùng để lưu tạm các báo cáo chờ gửi đi. Về lý thuyết, các file này phải được tải lên máy chủ, xử lý xong rồi xóa hoặc xoay vòng theo giới hạn. Nhưng trên thực tế, không có bước dọn dẹp nào diễn ra.

Người báo lỗi đầu tiên ghi nhận thư mục phình lên 4,9 GB với 54.504 file chỉ trong một ngày. Những bình luận sau đó cho thấy quy mô còn khủng khiếp hơn nhiều:

• Một người dùng báo thư mục đạt 58,89 GiB với 738.864 file, tốc độ khoảng một báo cáo mỗi giây.
• Một trường hợp khác lên tới 137,32 GiB với 1,78 triệu file.
• Đáng chú ý nhất là báo cáo tháng 10/2026: tổng cộng khoảng 323 GB với hơn 4 triệu file trên hai đường dẫn Crashpad, chiếm 35% ổ cứng 926 GB và khiến dung lượng trống chỉ còn 1,4 GB.

Thư mục Crashpad chứa hàng triệu file rác

Gốc rễ: trợ lý sự cố "tự báo cáo chính mình"

Điều khiến lỗi này khó hiểu ở giai đoạn đầu là ứng dụng vẫn hoạt động bình thường trong khi ổ cứng bị ăn mòn. Không có thông báo, không có cảnh báo — chỉ có dung lượng giảm dần.

Đến tháng 9/2026, một người dùng đã tìm ra nguyên nhân gốc. Toàn bộ file .dmp thực chất là minidump của chính tiến trình browser_crashpad_handler, chứ không phải của ứng dụng hay renderer. Mỗi file đều chứa cùng một lỗi chí mạng:

[FATAL:third_party/crashpad/crashpad/handler/mac/exception_handler_server.cc:76]
Check failed: kr == KERN_SUCCESS.
mach_port_request_notification: (os/kern) invalid capability (20)

Tiến trình này được khởi chạy với tham số --monitor-self-annotation, tức là nó tự giám sát chính nó. Chuỗi sự kiện diễn ra như sau:

• Handler gọi mach_port_request_notification và nhận mã lỗi KERN_INVALID_CAPABILITY.
• Nó dừng ở lệnh CHECK và chết.
• Cơ chế tự giám sát ghi lại một minidump về cái chết của chính nó.
• Handler được khởi động lại, gặp đúng lỗi cũ, và vòng lặp tiếp tục.

Đây là một vòng lặp không có điều kiện dừng, giải thích vì sao tốc độ tăng trưởng tuyến tính một cách hoàn hảo, khoảng 1 file mỗi giây, tương đương 15 GB/ngày khi ứng dụng đang chạy.

Vòng lặp sinh file dump của Crashpad

Hai lỗi riêng biệt bị gộp làm một

Các bình luận trong issue đã chỉ ra một điểm quan trọng: cần tách biệt hai vấn đề.

Thứ nhất, lỗi mach_port_request_notification không phải đặc thù của Codex. Cùng một thông báo lỗi trên macOS Tahoe 26.3.1 cũng được ghi nhận ở Claude Desktop và VS Code — đây là vấn đề của Crashpad kết hợp cơ chế Mach IPC trên macOS mới.

Thứ hai, việc tiêu tốn dung lượng không giới hạn lại độc lập với lỗi khởi động handler. Bất kỳ sự cố lặp lại nào ở bước khởi động cũng tạo ra thảm họa tương tự, bởi cơ chế tự giám sát coi mỗi lần chết của handler là một sự cố cần báo cáo, còn thư mục pending/ lại không có giới hạn kích thước hay thời gian tồn tại (TTL).

Một người dùng nhận xét thẳng thắn:

"Điều kỳ lạ là Crashpad có sẵn cơ chế dọn dẹp, nhưng ở đây nó không được triển khai. Tôi từng thấy hành vi này ở các ứng dụng Electron khác: handler được nối vào nhưng bộ dọn dẹp thì không, nên nếu telemetry bị tắt hoặc chặn, log cứ thế chất đống."

Một trường hợp đáng lưu ý khác cho thấy không cần vòng lặp sự cố dày đặc vẫn đủ gây họa: một người dùng ghi nhận thư mục pending/ chiếm 174,6 GB, tức 99,9% toàn bộ thư mục Application Support của ứng dụng, dù lần ghi cuối diễn ra từ 16 giờ trước. Chỉ với tốc độ trung bình khoảng 1,1 GB/ngày trong 5 tháng, không có cơ chế dọn dẹp nào can thiệp, con số này vẫn đạt tới mức phá hủy.

Người dùng tự cứu mình

Cho đến nay, chưa có bản vá chính thức nào được xác nhận. Cộng đồng đã chia sẻ nhiều cách xử lý tạm thời, từ nhẹ nhàng đến quyết liệt.

Kiểm tra trước đã. Trước khi xóa bất cứ thứ gì, người dùng nên đo dung lượng ở cả hai đường dẫn, vì các phiên bản khác nhau dùng vị trí khác nhau:

du -sh "$HOME/Library/Application Support/com.openai.codex/web/Crashpad/pending"
du -sh "$HOME/Library/Application Support/Codex/Crashpad/pending"

Xóa định kỳ. Một số người dùng đặt cron job dọn file mỗi 15 phút:

*/15 * * * * /usr/bin/find "$HOME/Library/Application Support/com.openai.codex/web/Crashpad/pending" -maxdepth 1 -type f -delete >/dev/null 2>&1 || true

Cách này chỉ kiềm chế dung lượng chứ không chặn được vòng lặp sinh file.

Khóa quyền ghi. Biện pháp triệt để hơn là xóa sạch thư mục rồi gỡ quyền ghi để handler không thể tạo file mới:

P="$HOME/Library/Application Support/Codex/Crashpad/pending"
find "$P" -type f -delete
chmod 500 "$P"

Nhiều người báo cáo cách này khiến dung lượng dừng tăng ngay lập tức. Tuy vậy, cần lưu ý đây là phanh khẩn cấp, không phải giải pháp lâu dài: nó vô hiệu hóa khả năng ghi báo cáo sự cố, che mất tín hiệu mà nhà phát triển cần để chẩn đoán, và cần được hoàn tác (chmod 700) sau khi lỗi được khắc phục.

Công cụ theo dõi và dọn dẹp cache trên macOS

Bài học cho hệ sinh thái công cụ AI

Sự việc phản ánh một vấn đề rộng hơn trong làn sóng ứng dụng AI chạy cục bộ. Khi các công cụ như Codex, Claude Desktop hay trợ lý lập trình được cài đặt ngày càng nhiều trên máy cá nhân, chúng thường kế thừa toàn bộ ngăn xếp Chromium/Electron đồ sộ mà không kiểm soát chặt chẽ vòng đời dữ liệu do mình sinh ra.

Một số người dùng trong issue không giấu được bức xúc:

"Cả Claude lẫn Codex đều chẳng có chút tôn trọng nào với máy của người dùng."

Về phía kỹ thuật, các đề xuất đưa ra khá rõ ràng và đều nằm trong tầm tay của nhà phát triển:

• Đặt giới hạn kích thước hoặc TTL cho thư mục pending/, đồng thời tự động xóa vòng.
• Chặn cơ chế tự giám sát báo cáo lỗi khởi động của chính handler, hoặc giảm tần suất/back-off sau N lần dump trùng lặp liên tiếp.
• Cảnh báo trong ứng dụng khi dữ liệu do nó tạo ra vượt vài GB.

Mỗi biện pháp trong số này đều đủ để biến thảm họa "ổ cứng về 0 byte" thành một dòng log vô hại. Với người dùng Việt Nam đang dùng Codex hay ChatGPT Desktop trên máy Mac — đặc biệt là các dòng máy có ổ cứng nhỏ và không thể nâng cấp — việc kiểm tra định kỳ thư mục trên là lời khuyên thiết thực nhất lúc này.