Codex Desktop Crashpad 버그 (이슈 #25921): macOS 디스크를 가득 채우는 무제한 대기 덤프

OpenAI의 macOS용 Codex Desktop 앱은 로컬 pending 디렉토리에 Crashpad 크래시 덤프를 지속적으로 생성하지만, 크기 제한, 만료 시간, 정리 기능이 없어서 앱 자체는 정상 작동하는 동안 폴더가 무한정 커집니다. GitHub 이슈 openai/codex#25921은 2026년 6월 2일 사용자 Jolg42가 연 문서로, 하루 만에 4.9GB와 54,504개의 파일이 생성된 최초 보고를 기록하고 있습니다. 이후 4개월간의 후속 댓글에서는 59GB, 61GB, 100GB, 137GB, 174GB, 그리고 한 머신의 두 Crashpad 경로에서 합계 약 323GB가 보고되었습니다.

이 이슈는 app, bug, performance 레이블이 붙어 있으며, 소스 스크랩 시점에 여전히 열려 있었습니다. 핵심 결함은 두 가지로 나눌 수 있습니다: 영향을 받는 macOS 버전에서 반복적으로 크래시하고 재시작되는 Crashpad 핸들러, 그리고 해당 크래시가 기록되는 디렉토리에 보존 제한이 전혀 없다는 점입니다.

버그의 실제 원인

Codex Desktop은 Chromium/Electron browser_crashpad_handler 헬퍼를 포함합니다. 영향을 받는 머신에서 이 핸들러는 시작 중 실패하고 자신의 미니덤프를 작성한 후 다시 실행되어 동일한 검사에 실패합니다. 각 반복은 Crashpad pending 큐에 .dmp 파일과 _sidecar.json 메타데이터 파일 쌍을 생성합니다.

사용자가 보는 증상은 Codex 앱의 크래시가 아닙니다. 앱은 계속 작동하며, 사용자는 같은 세션에서 앱과 상호작용하고 파일 시스템을 검사할 수 있는 반면, 디스크 사용량은 백그라운드에서 조용히 증가합니다. 앱 내에서 경고를 표시하지 않습니다.

버전별 보고된 디스크 사용량

증가 규모는 머신과 루프가 감지되지 않고 실행된 시간에 따라 크게 달랐습니다.

리포터	날짜	앱 버전	보고된 크기	파일 수
Jolg42 (작성자)	2026-06-02	26.527.60818	하루 4.9GB	54,504
mxggle	2026-06-07	—	59GB	65,535 파일 한도 도달
dionylon	2026-06-09	26.602.71036	58.89GiB	738,864
guojianlan	2026-06-18	26.611.62324	137.32GiB	1,786,086
libairi	2026-07-21	26.715.70719	약 33.4GiB	—
austinhutchison	2026-08-15	26.803.61601	약 100GB	약 100만 개
dewalt-1	2026-09-02	26.818.41509	174.6GB	약 108만 덤프, 200만 개 이상 파일
ashtonsix	2026-10-05	26.930.21537	114.22GB	1,212,428
ahmedkhan25	2026-10-17	26.1007.71326	두 경로 합계 약 323GB	약 404만 개

최초 보고에서는 27,252개의 .dmp 파일과 27,252개의 _sidecar.json 파일(정확히 1:1 쌍)이 총 4.9GB로 측정되었습니다. 작성자가 내용을 삭제한 후 디렉토리는 6.4MB와 70개 파일로 줄었지만, 새 쌍 파일이 즉시 나타나 활성 생성이 진행 중임을 확인했습니다(오래된 백로그가 아님).

정확한 핸들러 실패

여러 리포터가 가장 최신 .dmp 파일에서 동일한 치명적 메시지를 추출했습니다. 이 메시지는 Codex 앱이나 렌더러가 아닌 Crashpad 자체 예외 처리기 서버에서 발생합니다:

[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)

덤프에는 충돌 프로세스가 핸들러 자체임을 식별하는 주석이 포함되어 있습니다:

executable_path=/Applications/ChatGPT.app/Contents/Frameworks/Codex Framework.framework/Versions/152.0.7977.64/Helpers/browser_crashpad_handler
--monitor-self-annotation=ptype=crashpad-handler
ptype=crashpad-handler

macOS의 진단 로그도 이를 뒷받침합니다. 리포터들은 ~/Library/Logs/DiagnosticReports 아래에서 procName: browser_crashpad_handler, exception: EXC_BREAKPOINT / SIGTRAP, coalitionName: com.openai.codex 항목이 포함된 반복적인 .ips 항목을 발견했습니다.

루프가 종료되지 않는 이유

사용자 ReymondAkpanya는 2026년 9월 21일 댓글에서 자기 유지 주기에 대한 가장 명확한 설명을 제공했습니다. 핸들러가 --monitor-self-annotation으로 실행되기 때문에 자기 자신을 모니터링합니다. 순서는 다음과 같습니다:

핸들러가 mach_port_request_notification을 호출하고 KERN_INVALID_CAPABILITY (20)을 받습니다.
exception_handler_server.cc:76의 CHECK에서 실패하여 종료됩니다.
자기 모니터가 핸들러의 미니덤프를 작성합니다.
핸들러가 다시 실행되고 동일한 검사에 실패하여 2단계로 돌아갑니다.

기본 사례가 없는 루프이므로 증가가 완벽하게 선형적이며 앱 활동과 상관관계가 없습니다.

해당 보고에서 측정된 속도: 정확히 초당 1개의 덤프, 각각 181,552바이트, 24바이트 _sidecar.json — 시간당 약 3,600개 덤프, 시간당 약 0.6GB, 앱 실행 중 하루 약 15GB. 이 경우 큐는 240,966개 파일과 21GB에 도달했고 228GB 디스크를 0바이트로 만들었습니다. completed/ 디렉토리는 240,966개 보고서 모두에서 비어 있었으며, 큐를 비우는 메커니즘이 전혀 없음을 의미합니다.

업스트림 원인은 Codex 특정 문제가 아님

mach_port_request_notification / KERN_INVALID_CAPABILITY 실패는 Crashpad-on-macOS Mach IPC 문제로, Codex에만 국한되지 않습니다. macOS Tahoe 26.3.1에서 동일한 오류가 Claude Desktop (anthropics/claude-code#37230) 및 VS Code (microsoft/vscode#282433)를 포함한 다른 Chromium/Electron 애플리케이션에서도 보고되었습니다.

이 구분은 버그를 평가하는 모든 사람에게 중요합니다. 업스트림 CHECK 실패는 환경적 요인입니다. 무제한 디스크 소비는 그렇지 않습니다 — 반복 가능한 핸들러 시작 실패는 동일한 폭주를 생성합니다. 왜냐하면 자기 모니터가 핸들러 자신의 치명적 CHECK를 보고 가능한 크래시로 취급하기 때문입니다. ReymondAkpanya의 말처럼, 트리거는 업스트림이지만 증폭은 그렇지 않습니다.

보존 버그는 크래시 루프와 독립적

사용자 dewalt-1은 이 두 가지가 별개의 결함이라는 가장 강력한 주장을 했습니다. 2026년 9월 2일, 그들은 ~/Library/Application Support/Codex/Crashpad/pending에서 174.6GB를 보고했으며, Application Support/Codex의 다른 모든 항목은 171MB에 불과했습니다 — 디렉토리의 99.9%. 덤프는 균일한 약 161KB 쌍으로, 약 108만 개 덤프와 200만 개 이상의 파일이었습니다.

결정적으로, 그 머신은 빠른 루프 상태가 아니었습니다: pending/에 대한 마지막 쓰기는 16시간 전이었고 앱은 그 이후로 실행되었지만 추가되지 않았습니다. Crashpad/ 디렉토리는 2026-04-05에 생성되었으며, 5개월 동안 평균 하루 약 1.1GB(5-17GB/일이 아님)를 의미합니다.

덤프를 생성하는 것이 무엇이든, 그것을 정리하는 것은 없습니다. 보존 버그는 특정 크래시 루프와 분리 가능해 보입니다: 낮은 크래시율도 5개월이면 175GB에 도달합니다. pending/에 크기 또는 기간 제한을 두면 크래셔를 수정하지 않아도 피해를 제한할 수 있습니다.

사용자 jakehop은 2026년 8월 9일에 Crashpad에 이 통합에서 구현되지 않은 프루너가 포함되어 있다고 언급했습니다: "다른 Electron 앱에서도 이 동작을 봤습니다. 핸들러는 연결되어 있지만 프루너는 연결되어 있지 않아서, 텔레메트리가 꺼져 있거나 차단되면 이러한 로그가 pending에 계속 쌓일 것입니다."

영향을 받는 경로 및 버전

보고서에는 두 개의 Crashpad 데이터베이스 경로가 나타나며, 같은 머신에서 둘 다 영향을 받을 수 있습니다:

~/Library/Application Support/com.openai.codex/web/Crashpad/pending — 초기 Codex Desktop 빌드에서 사용된 레거시 경로.
~/Library/Application Support/Codex/Crashpad/pending — 통합 ChatGPT/Codex 데스크톱 앱에서 사용되는 최신 경로.

ahmedkhan25는 2026년 10월 17일에 두 경로를 동시에 측정했습니다: 레거시 경로에 180GB / 2,251,765개 파일, 최신 경로에 143GB / 1,785,095개 파일, 합계 약 323GB 및 약 404만 개 파일 — 926GB 디스크의 약 35%. 발견하기 전에 여유 공간이 1.4GB로 줄었습니다.

보고된 앱 버전은 26.527.60818(6월)부터 26.1007.71326 빌드 20398(10월)까지이며, Chromium 프레임워크 버전은 148.0.7778.179에서 155.0.8059.40까지입니다. 보고서에서 영향을 받는 macOS 버전은 15.x 및 26.0–26.3에 집중되어 있습니다.

버전 및 플랫폼 신호

기여자 dnakov는 2026년 6월 14일에 "이 문제는 이후 macOS 버전에서 수정된 것 같습니다. 적어도 26.5에서는 그렇습니다."라고 댓글을 달았습니다. 사용자 nathanvy는 2026년 10월 18일에 macOS 26.6.2에서 codex v26.1013.40934 빌드 20770을 실행 중이며 영향을 받지 않았다고 보고했습니다.

이 패턴 — 15.x 및 26.0–26.3에서 영향, 26.5+에서 무영향 — 은 Mach IPC 실패가 커널 버전에 의존적임을 시사합니다. 그러나 스레드에는 최신 빌드 및 최신 경로에 대한 보고도 포함되어 있으며, libairi는 앱 빌드만 롤백해도 도움이 되지 않는다는 것을 발견했습니다: 빌드 5538 (26.715.31251)과 빌드 5650은 둘 다 Chromium 150.0.7871.124를 사용하고, 동일한 Mach-O UUID를 공유하며, 서명되지 않은 코드 영역에 대해 동일한 SHA-256 해시를 가집니다.

사용자들이 보고한 해결 방법

1. 대기 보고서 삭제

가장 간단한 차단은 pending 디렉토리 내부의 파일을 직접 삭제하는 것입니다. 작성자의 cron 항목(2026년 6월 20일 게시):

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

crontab -e로 설정하고 crontab -l로 확인하십시오. 이 명령은 pending 디렉토리 내부의 파일만 삭제합니다.

2. pending 디렉토리를 읽기 전용으로 만들기

여러 사용자가 디렉토리를 비운 후 쓰기 권한을 제거하여 증가를 멈췄습니다. ReymondAkpanya의 버전:

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

그들은 증가가 멈추고 new/, completed/, attachments/로 아무것도 넘치지 않는다는 것을 확인했습니다 — 전체 Crashpad 디렉토리는 20K로 유지됩니다. chmod 700으로 되돌립니다.

dionylon은 전체 데이터베이스에 더 강력한 변형을 사용했습니다: pending, new, completed, attachments 하위 디렉토리를 다시 만든 후 chmod -R 555와 chflags -R uchg를 결합했습니다. 관찰 기간 동안 pending을 0으로 유지했습니다. 그들은 macOS가 sudo로도 핸들러 바이너리 자체를 수정하는 것을 허용하지 않는다고 언급했습니다 (Operation not permitted).

3. 삭제 대신 휴지통으로 이동

사용자 liuminsheng3는 전체 앱 데이터 디렉토리를 삭제하는 대신 Crashpad 보고 버킷만 휴지통으로 이동하고, 먼저 핸들러를 중지할 것을 권장했습니다:

osascript -e 'quit app "Codex"' 2>/dev/null || true
pkill -f "browser_crashpad_handler.*codex.*/Crashpad" 2>/dev/null || true

for crash in \
  "$HOME/Library/Application Support/com.openai.codex/web/Crashpad" \
  "$HOME/Library/Application Support/Codex/Crashpad"; do
  [ -d "$crash" ] || continue
  mkdir -p "$HOME/.Trash/Codex-Crashpad"
  for bucket in pending new completed attachments; do
    [ -d "$crash/$bucket" ] || continue
    find "$crash/$bucket" -mindepth 1 -maxdepth 1 -exec mv {} "$HOME/.Trash/Codex-Crashpad/" \;
  done
done

이것은 대규모에서 중요합니다: ahmedkhan25는 수백만 개의 작은 파일을 삭제하는 것은 느리지만, 폴더 이름을 바꾸는 것은 즉각적이라고 보고했습니다. its-tahir도 같은 조언을 했습니다 — "Crashpad 폴더를 휴지통으로 이동하세요. 수백만 개의 파일이 있어도 즉각적이며, 4M 파일에 rm을 사용하는 것은 느립니다."

4. LaunchAgent를 통한 제한된 보존

ashtonsix는 5분마다 실행되는 LaunchAgent를 설치하여 24시간보다 오래된 보고서를 만료시키고 각 pending/completed 큐를 64개 보고 그룹과 256MiB로 제한했습니다. 일치하는 UUID 덤프/사이드카 파일을 그룹화하고, 새 쓰기에 2분의 유예 기간을 부여하며, 알 수 없는 파일, 심볼릭 링크, 검사 중 변경되는 파일을 건너뜁니다. 그들은 이것을 데이터베이스를 쓰기 불가능하게 만들지 않고 진단 저장 공간을 제한하는 것으로 명시했으며, 충돌하는 헬퍼를 수리하는 것이 아니라고 했습니다.

효과가 없었던 해결 방법

libairi는 통합 앱에서 여러 접근 방식을 테스트했고 모두 효과가 없다고 보고했습니다:

--disable-breakpad로 시작해도 새 Crashpad 보고서가 생성되는 것을 막지 못했습니다.
핸들러 실행을 거부하면 pending 덤프가 중지되었지만 반복적인 macOS "ChatGPT가 예기치 않게 종료되었습니다" 보고와 팝업이 발생했습니다.
주기적으로 Crashpad/pending만 삭제하면 디스크 사용량은 제한되지만 핸들러 크래시 루프는 수정되지 않습니다.

dionylon은 또한 전체 재설치로 해결되지 않았고, browser@openai-bundled 비활성화, chrome@openai-bundled 비활성화, ~/.codex/config.toml에서 BROWSER_USE_AVAILABLE_BACKENDS = "" 설정이 재시작 후 덤프 증가를 막지 못했다고 보고했습니다.

읽기 전용 해결 방법에 대한 안전 주의

사용자 liuminsheng3는 Crashpad/pending을 읽기 전용으로 만드는 것은 기본 정리 경로가 아닌 비상 브레이크로 취급해야 한다고 경고했습니다. 활성 덤프 루프를 중지하지만 Codex가 크래시 보고서를 작성하는 것을 방지하고 유지 관리자가 필요한 신호를 숨길 수 있습니다. 범위를 좁게 유지하고 ~/Library/Application Support/Codex, ~/Library/Application Support/com.openai.codex, 임시 com.openai.codex.code_sign_clone 디렉토리에서 영구적인 읽기 전용 상태를 피할 것을 권장했습니다.

그들이 제안한 순서: Codex 종료; Crashpad 보고 버킷만 휴지통으로 이동; 재시작하고 pending이 다시 자라는지 관찰; 적극적으로 다시 채워지는 경우에만 읽기 전용 해결 방법 적용; 앱 또는 버전 문제가 해결된 후 읽기 전용 비트 해제.

영향을 받는지 확인하는 방법

its-tahir는 스레드에 간결한 분류 요약을 게시했습니다. 두 Crashpad 경로의 크기를 확인하십시오:

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

지금 덤프가 작성되고 있는지 확인하십시오 — 지난 1분 동안 약 60개의 .dmp 파일이 있으면 루프가 실행 중임을 의미합니다:

find "$HOME/Library/Application Support/Codex/Crashpad/pending" \
  -maxdepth 1 -name '*.dmp' -mmin -1 | wc -l

그런 다음 앱을 종료하고 pgrep -fl browser_crashpad_handler로 남은 핸들러를 확인한 후 Crashpad 폴더를 휴지통으로 이동하십시오.

덤프를 공개적으로 공유해서는 안 되는 이유

증거를 첨부한 모든 리포터는 원시 .dmp 파일을 공개하지 않았습니다. 원저자는 "미니덤프에는 메모리, 로컬 경로 또는 개인 데이터가 포함될 수 있으므로 공개적으로 첨부하지 않습니다. OpenAI 유지 관리자가 안전한 업로드 경로를 제공하면 최신 .dmp를 비공개로 공유할 수 있습니다."라고 밝혔습니다. 이후 여러 댓글 작성자도 덤프에 메모리, 로컬 경로, 프롬프트 또는 프로젝트 상태가 포함될 수 있다는 점을 언급하며 같은 주의를 반복했습니다. 메타데이터 — 개수, 크기, 가장 오래된/최신 타임스탬프, 앱 버전, 어떤 경로가 계속 증가하는지 — 는 공개 분류에 충분하다고 간주되었습니다.

Hacker News에서의 커뮤니티 반응

Hacker News 토론(156점, 73개 댓글)은 기술적 메커니즘보다는 패턴에 더 초점을 맞췄습니다. 여러 댓글 작성자는 이것이 SSD 마모 영향이 있는 첫 번째 Codex 버그가 아니라고 언급했습니다. 한 명은 무한 로깅을 수행한 이전 Codex 이슈를 언급했습니다.

"이것은 SSD에 큰 내구성 영향을 미칠 수 있는 두 번째 Codex 버그입니다. 첫 번째 버그만큼 심각하지는 않지만, 첫 번째는 무한 로깅을 했습니다."

다른 사람들은 Crashpad보다는 인접한 원인으로 인한 디스크 압력을 보고했습니다. 한 댓글 작성자는 디스크 사용량을 동시 기능 전반에 걸쳐 빌드 아티팩트를 복제하는 git worktrees와 메모리 한계 도달로 인한 과도한 macOS 스왑으로 추적했습니다. 다른 사람은 Codex worktrees에 남겨진 수천 개의 스크린샷과 아티팩트, Windows VM에서 생성된 90GB의 불필요한 검증 테스트를 보고했습니다. 그 댓글 작성자는 "이것은 확실히 Codex 문제이며 Claude Code나 Antigravity에서는 이런 일이 발생하는 것을 본 적이 없습니다."라고 덧붙였습니다.

별도의 댓글 작성자는 ~/.bun/install/cache/@openai에서 각각 약 300MB인 11개의 중복 codex 및 codex-code-mode-host 바이너리를 발견했습니다. 다른 사람은 .staging/marketplace 디렉토리에 14GB의 작은 파일을 보고했습니다.

여러 댓글은 초기 보고와 수정 사이의 4개월 간격을 강하게 비판했습니다. 한 명은 Crashpad 자체 프루너가 존재하지만 이 통합에서는 연결되어 있지 않다고 언급했습니다. 다른 사람은 사용자가 핵심 제품의 버그를 수정받는 대신 해결 방법을 요구받고 있다고 관찰했습니다.

스레드의 실용적인 제안에는 에이전트 하네스를 Docker 컨테이너로 격리, DaisyDisk와 같은 디스크 시각화 도구를 사용하여 증가를 찾기, ChatGPT 앱 설정의 저장소 섹션(사용된 디스크 공간 표시) 확인이 포함되었습니다.

수정이 해결해야 할 사항

ReymondAkpanya는 각각 최악의 결과를 방지했을 두 가지 독립적인 완화를 제안했습니다:

자기 모니터가 핸들러 자신의 시작 CHECK 실패를 보고하지 않도록 중지하거나, N개의 연속 동일 덤프 후 백오프 및 속도 제한. 이렇게 하면 업스트림 원인과 관계없이 루프가 끊어집니다.
pending/에 크기 제한 또는 TTL 적용하여 조용히 실패하는 업로드 경로가 디스크를 채울 수 없도록 합니다.

둘 중 하나라도 "디스크 0바이트"를 로그 한 줄로 바꿨을 것입니다.

ahmedkhan25는 같은 취지로 세 가지 요청을 추가했습니다: 자동 정리 기능이 있는 Crashpad/pending의 크기 또는 개수 제한; 핸들러 크래시 루프 수정; Codex 자체 데이터가 몇 GB를 초과할 때 앱 내 경고.

상태

이 이슈는 소스 스크랩 시점에 app, bug, performance 레이블과 함께 열려 있었습니다. 스레드의 가장 최근 보고(2026년 10월)는 앱 버전 26.1007.71326 빌드 20398 및 두 Crashpad 경로 모두에서 버그를 설명합니다. 기여자 댓글은 이후 macOS 버전(26.5 이상)이 영향을 받지 않는다고 제안했고, macOS 26.6.2 사용자 한 명은 영향이 없다고 보고했습니다 — 그러나 스레드에는 최신 빌드 보고와 인접 빌드 간 핸들러 바이너리가 변경되지 않았다는 증거도 포함되어 있습니다. 공식 수정이나 보존 제한은 스레드에서 확인되지 않았습니다.