OpenAI Codex 데스크톱이 크래시 덤프로 맥 디스크를 무한정 채운다

Hacker News14일 전조회 1

OpenAI의 Codex 데스크톱 앱이 macOS에서 Crashpad 대기 덤프를 끝없이 쌓아 로컬 디스크를 잠식하는 문제가 GitHub 이슈 #25921로 제기됐다. 앱을 실행해 작업하는 데는 문제가 없어도, 백그라운드에서 .dmp와 _sidecar.json 파일이 쌍을 이뤄 생성되며 저장 공간을 계속 먹는 것이 핵심이다.

문제 경로는 ~/Library/Application Support/com.openai.codex/web/Crashpad/pending이다. 첫 제보자는 Codex 26.527.60818에서 하루 만에 4.9GB, 54,504개 파일이 쌓였다고 적었다. 조사 중에도 파일 수가 53,444개에서 54,064개, 다시 54,504개로 늘어 단순한 과거 잔여물이 아니라 실시간 생성임을 보여줬다. 대기 파일을 지우면 6.4MB, 70개 수준으로 줄었지만 곧 새 덤프와 사이드카가 다시 생겼다.

다른 사용자 제보는 규모가 더 크다. 한 사용자는 59GB까지 늘었고 65,535개 파일 한계에 닿은 뒤에도 백그라운드 프로세스가 덤프를 만들려 했다고 전했다. 더 새로운 빌드 26.602.71036에서는 대기 디렉터리가 약 61GB까지 커졌으며, 정리와 재설치, 재시작 뒤에도 초당 한 건꼴로 보고서가 생겼다는 관찰이 나왔다.

최신 덤프에는 browser_crashpad_handler 자체의 치명적 오류가 담겼다. mach_port_request_notification에서 invalid capability(20)가 발생해 KERN_SUCCESS 검사가 실패했다는 내용이며, 시스템 로그에서도 같은 핸들러의 EXC_BREAKPOINT/SIGTRAP 반복이 확인됐다. 즉 앱 본체의 일반적인 크래시라기보다 Crashpad 핸들러가 재시작과 덤프 생성을 반복하는 루프에 가까워 보인다는 분석이다.

배경에는 Codex 데스크톱의 Chromium/Crashpad 경로가 있다. Crashpad는 원래 충돌 보고를 모아 업로드하거나 처리하고 오래된 파일을 회전·정리해야 하는데, 이 사례에서는 대기 큐가 상한 없이 커졌다. 한 제보자는 인앱 브라우저인 Browser Use가 사용 불가 상태가 된 뒤 Browser Use/IAB 수명주기 로그가 반복됐고, 얼마 지나 Crashpad 덤프가 급증했다고 적었다. 다만 이것이 원인이라고 확정된 것은 아니다.

우회 시도도 쉽지 않았다. macOS가 /Applications/Codex.app 내부의 browser_crashpad_handler를 sudo로도 수정하지 못하게 막았고(Operation not permitted), 한 사용자는 사용자 Crashpad 데이터베이스를 읽기 전용·불변으로 바꿔 디스크 증가를 멈추는 임시 조치를 취했다. browser@openai-bundled와 chrome@openai-bundled를 끄고 BROWSER_USE_AVAILABLE_BACKENDS를 빈 값으로 두는 설정만으로는 증가가 멈추지 않았다는 보고도 있다.

맥에서 Codex 데스크톱을 쓰는 개발자라면 이 경로의 용량과 파일 수를 한 번 확인할 필요가 있다. 디스크가 차면 빌드, 패키지 설치, Git 작업, IDE 캐시 생성이 연쇄적으로 실패할 수 있고, 파일 수가 파일시스템 한계에 가까워지면 다른 정상 파일 생성까지 막힐 수 있다. 당장 앱이 멀쩡해 보여도 백그라운드에서 공간이 줄고 있을 수 있다는 점이 이 버그의 위험한 부분이다.

현재 내용은 GitHub 이슈에 올라온 사용자 제보와 진단에 기반한다. OpenAI가 공식적으로 원인을 확정하거나 수정 버전을 안내했다는 내용은 확인되지 않는다. 또한 덤프에는 메모리, 로컬 경로, 개인 데이터가 포함될 수 있어 제보자는 minidump를 공개하지 않았다. 모든 Codex 데스크톱 사용자에게 같은 규모로 발생한다고 단정하기는 어렵지만, macOS 환경에서 반복 재현 사례가 나온 만큼 모니터링과 백업, 임시 정리 계획을 세우는 편이 안전하다.