Codex is EATING my Mac's disk space

openai/codex 이슈 #25921 본문과 주요 댓글을 읽고 옮겼어요. 댓글 끝부분의 긴 진단 스크립트는 요약만 했어요.

증상

최초 작성자(Jolg42, 2026-06-02)는 macOS용 Codex Desktop이 다음 경로에 .dmp와 _sidecar.json 쌍을 계속 만든다고 보고했어요.

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

• 하루 만에 4.9GB, 파일 54,504개(덤프 27,252개 + sidecar 27,252개)로 불어났고, 조사하는 동안에도 53,444 → 54,064 → 54,504개로 늘었어요.
• 앱은 정상적으로 쓸 수 있었어요. 즉 앱이 죽는 게 아니라, 뒤에서 Crashpad가 보고서를 무한정 만들고 정리·업로드·순환을 하지 않는 게 문제예요.
• PPID=1로 떠 있는 browser_crashpad_handler 프로세스 두 개가 같은 DB를 쓰고 있었어요.
• 파일을 지우자 6.4MB로 줄었지만 새 덤프가 바로 다시 생겼어요.

다른 사용자들의 보고

| 보고자 | 내용 | |---|---| | mxggle | 59GB까지 찼고, 파일 수 한도(65535)에 닿아도 계속 쓰려 함 | | dionylon | 약 61GB, 파일 738,864개. 정리·재설치 후에도 초당 약 1개 속도로 증가 | | Cuimc | 하루에 22GB 정리 | | changjonathanc | 26.601.10930 버전에서도 같은 문제 |

핵심 단서

dionylon은 최신 덤프 안에서 browser_crashpad_handler 자신의 FATAL 메시지를 찾았어요(mach_port_request_notification: invalid capability). 크래시 핸들러가 스스로 죽고 다시 뜨기를 반복하며 자기 덤프를 쓰는 루프로 보인다는 분석이에요. 시스템 로그에도 EXC_BREAKPOINT / SIGTRAP가 반복됐고, 앱 내 브라우저(Browser Use) 경로와 관련 있을 수 있다고 했어요. 재설치나 브라우저 플러그인 비활성화로는 해결되지 않았어요.

임시 우회법과 반응

• Crashpad DB 폴더를 비운 뒤 chmod -R 555와 chflags -R uchg로 읽기 전용·변경 불가로 만들면 pending이 0으로 유지됐다고 해요. 다만 크래시 보고 자체를 막는 것이라 근본 해결은 아니라고 본인이 밝혔어요.
• 기여자 dnakov는 "최신 macOS(26.5)에서는 고쳐진 것 같다"고 댓글을 달았어요.
• 다른 사용자는 /System/Library/Caches/com.apple.coresymbolicationd/data에도 크래시 관련 파일이 계속 쌓이는지 확인하는 스크립트를 공유했어요.