Codex Mac 앱이 충돌 덤프 파일로 디스크를 가득 채울 수 있습니다. 최신 보고서에 따르면 323GB에 달합니다

• 도서: System Design Pocket Guide: Fundamentals
• 저자 소개: Thinking in Go (2권 시리즈) — Complete Guide to Go Programming + Hexagonal Architecture in Go
• 프로젝트: Hermes IDE | GitHub — Claude Code 및 기타 AI 코딩 도구와 함께 배포하는 개발자를 위한 IDE
• 저자: xgabriel.com | GitHub

10월 17일, 한 Mac 사용자가 6월 2일부터 열려 있던 Codex GitHub 이슈에 표를 추가했습니다. 충돌 보고서 폴더 두 개와 약 4백만 개의 파일로 구성되어 있으며, 용량은 대략 323GB입니다. 이 사용자는

• 원문 보고서는 6월 2일 기준 하루에 4.9 GB와 54,504개의 파일을 기록했습니다.
• 앱 버전 26.727.51351에 대해 제기된 이슈 #36982는 발생률을 “~17GB/일”로 제시합니다.
• macOS 15.2에서 9월 23일에 열린 이슈 #47466은 폴더 크기가 약 511 GB이며, 앱을 실행하는 동안 초당 한 번씩 발생하는 약 160 KB의 미니덤프(minidump) 파일이 있다고 보고합니다.
• 10월 6일자 이슈 #51361은 130.53 GiB 크기를 보고했으며, 남은 여유 공간은 약 821 MiB이고 임시 파일(temp files)들이 “no space left on device” 오류로 실패하고 있다고 합니다.
• 10월 8일자 이슈 #52194는 약 168 GB와 대략 197만 개의 파일을 보고했습니다.
• 10월 16일 포럼 게시물은 충돌 보고서가 약 230 GB를 소비했다고 추정합니다.
• 10월 17일 댓글에서는 빌드명: ChatGPT.app 26.1007.71326을 언급했습니다.

이러한 상황에서도 앱은 계속 작동합니다. 최초 보고자는 사용 가능한 상태를 유지했다고 언급했으며, 이것이 바로 아무도 확인하지 않는 동안 폴더가 몇 주 동안 커질 수 있는 이유입니다.

폴더가 비워지지 않는 이유

Crashpad는 Chromium 프로젝트의 충돌 보고서 도구로, “사후(postmortem) 충돌 보고서를 캡처, 저장 및 전송하기 위한 라이브러리”입니다. 이 데이터베이스에는 “업로드 대기 중인 충돌 덤프(crash dumps pending upload)”가 보관됩니다. 이것들이 pending 폴더에 있는 파일들입니다.

가장 유력한 설명은 OpenAI가 아닌 사용자들로부터 나오고 있습니다. #25921에서 한 보고자는 모든 덤프 파일이 크래시 핸들러 자체인 browser_crashpad_handler의 것이라고 발견했으며, 여러 다른 사용자들은 동일한 시작 실패를 언급했습니다. 이 과정은 mach_port_request_notification을 호출할 때 "(os/kern) invalid capability (20)"을 반환하고, 검사에서 Check failed: kr == KERN_SUCCESS.가 실패하며 프로세스가 종료됩니다. 이후 재시작되고 다시 실패하면서 또 다른 덤프 파일을 작성합니다. #36982의 제목이 이를 요약하고 있습니다: 핸들러는 "실행 후 2ms 만에 SIGTRAPs를 발생시키고, launchd가 재시작합니다". #25921의 한 댓글 작성자는 macOS Tahoe 26.3.1에서 다른 Chromium 및 Electron 앱에서도 같은 오류를 보고했습니다.

문제의 두 번째 부분은 폴더를 정리하는 것이 전혀 없다는 점입니다. Crashpad의 설계 문서에는 "데이터베이스는 설정 가능한 최대 집합 크기까지 기록된 크래시 덤프 파일의 개수를 저장합니다."라고 명시되어 있습니다. #25921의 한 댓글 작성자는 앱이 Crashpad의 프루너(pruner)를 사용하지 않는다고 말했습니다. Issue #51361에서는 OpenAI에 기본적으로 저장 용량 제한 및 정리 기능을 활성화해 달라고 요청했으며, 이 이슈는 아직 담당자가 지정되지 않은 채 열려 있습니다.

수정되었나요?

부분적으로만요. 10월 6일, 해당 레포지토리의 기여자 중 한 명이 #47466에서 "이것은 구형 Mac 커널의 문제인 것 같습니다."라고 작성했습니다. 같은 댓글에 "수정 사항이 병합되었으며 곧 출시될 예정입니다."라고 덧붙였습니다. 이 이슈는 그날 폐쇄되었습니다. 10월 7일, 한 사용자가 수정된 빌드가 어떤 버전인지 그리고 이미 거대한 큐를 정리하는지 문의했지만, 해당 스레드에는 답변이 없습니다.

이전에, 6월 14일 한 기여자(contributor)가 #25921에서 다음과 같이 작성했습니다: "저는 이것이 나중에 나온 macOS 버전에서는 수정되었다고 생각합니다. 적어도 26.5 버전에서는 그렇습니다." 이후 보고한 사람들은 macOS 26.0부터 26.3까지 여전히 증가를 목격했으며, #47466 report는 macOS 15.2에서 나온 것입니다.

10월 17일 보고서는 macOS 15.7.4의 빌드 26.1007.71326에 관한 것입니다. 이 빌드가 10월 6일 수정 사항을 포함하는지는 스레드에서 언급하지 않습니다. #25921은 여전히 열려 있습니다.

#52194에서 나온 또 다른 데이터 포인트는 다음과 같습니다: 보고자는 이전 프레임워크 버전의 핸들러 프로세스 두 개가 여전히 실행 중인 것을 발견했지만, 해당 버전은 더 이상 디스크에 존재하지 않았습니다. 프로세스를 종료해도 도움이 되지 않았습니다. macOS 재부팅이 이 루프를 멈추게 했습니다.

Mac 확인하기

해당 문제는 두 위치를 나열합니다: 이전 위치와 새로운 위치입니다. du로 둘 다 측정하세요:

cd ~/Library/"Application Support"
du -sh Codex/Crashpad/pending \
  com.openai.codex/web/Crashpad/pending 2>/dev/null

결과가 기가바이트(gigabytes) 단위라면, 덤프 파일이 쌓이고 있다는 의미입니다. 이것이 여전히 증가하고 있는지 확인하려면 find로 파일을 세고, 앱을 열어 분당 두 번 측정하세요. 이 명령어는 동일한 폴더에서 실행됩니다. 만약 com.openai.codex/web/Crashpad/pending이 큰 용량이었다면, 해당 경로를 바꿔서 사용하세요:

find Codex/Crashpad/pending -type f | wc -l
du -sh Codex/Crashpad/pending; sleep 60
du -sh Codex/Crashpad/pending

그런 다음 핸들러 프로세스가 실행 중인지 확인하세요:

pgrep -lf browser_crashpad_handler

폴더가 클 경우

먼저 앱을 종료하세요. #52194 보고자는 OpenAI 지원팀으로부터 앱을 닫은 상태에서 보류 중인 리포트를 삭제하라고 들었다고 합니다. 실행 중인 핸들러가 사용자가 파일을 삭제하는 동안에도 새로운 덤프를 계속 추가합니다. 수백만 개의 파일이 있는 경우, rm pending/*는 셸이 모든 이름을 하나의 인자 목록으로 확장하기 때문에 실패합니다. 대신 find -delete를 사용하세요:

cd ~/Library/"Application Support"
find Codex/Crashpad/pending -type f -delete

만약 com.openai.codex/web/Crashpad/pending 폴더도 크다면 동일한 명령어를 실행하세요. 그런 다음 재부팅합니다. #52194에서 효과가 있었던 방법입니다. 앱을 다시 열고 성장 확인(growth check)을 다시 실행하세요.

만약 폴더가 계속 커진다면, #25921의 사용자들은 고정된 빌드가 배포될 때까지 타이머를 이용해 정리 작업을 수행합니다. 이 명령어는 24시간보다 오래된 덤프를 제거합니다:

find Codex/Crashpad/pending -type f -mtime +0 -delete

일부 댓글 작성자들은 대신 chmod를 사용해 pending 폴더를 읽기 전용으로 만들었습니다. 다른 사람들은 이 방법이 실제 충돌 보고서가 OpenAI에 도달하는 것을 막을 수 있다고 경고했으므로, 만약 그렇게 한다면 업데이트 후에 되돌리세요.

배포하는 모든 로컬 큐는 용량 제한이 필요합니다

업로드 성공 시에만 내용물이 빠지는 폴더는 큐(queue)입니다. 소비자(consumer)가 절대 실행되지 않으면, 큐는 디스크가 가득 찰 때까지 커지고 앱의 어떤 부분도 이상해 보이지 않습니다. Crashpad에는 이미 이를 포함할 수 있는 두 가지 제한이 있습니다: 개수와 총 크기. 이들은 설정되어야 합니다.

사용자 자체 도구가 작성하는 것에도 마찬가지입니다: 에이전트 스크립트(agent transcripts), 재시도 큐(retry queues), 디버그 로그(debug logs), 충돌 보고서(crash reports). 각각에 용량 제한과 시간 제한을 부여하고, 디스크가 거의 가득 찼을 때 기록하는 양을 줄이도록 해야 합니다. 이는 #51361에서 Codex에게 요청한 내용입니다.

만약 Codex를 Claude Code 및 다른 에이전트와 함께 사용한다면, 저는 Hermes IDE를 구축했으니 이 점을 고려해 주세요. 다운로드하는 것은 무료이며, 소스 코드를 공개했고, macOS, Windows, Linux에서 실행되며, 각 작업에 자체 브랜치와 워크트리를 할당할 수 있어 에이전트들이 서로 간섭하지 않습니다(GitHub).

소비자가 절대 실행되지 않는 무한 큐는 전형적인 시스템 설계 실패 사례이며, 이는 충돌 보고서에서 멀리 떨어진 곳에서도 나타납니다. System Design Pocket Guide: Fundamentals에서는 속도 제한(rate limits)부터 가용성(availability)에 이르기까지 이러한 이야기의 근간이 되는 빌딩 블록들을 다루고 있어, 하나의 멈춘 컴포넌트가 전체 시스템을 다운시키지 않도록 합니다.