오픈AI의 데스크톱 앱인 코덱스(Codex)가 macOS에서 크래시 덤프 파일을 멈추지 않고 쌓으면서 로컬 디스크를 통째로 갉아먹는 문제가 깃허브 이슈(openai/codex #25921)로 보고됐다. 증상은 단순하지만 파급은 작지 않다. 앱 지원 디렉터리 아래 Crashpad의 pending 폴더에 확장자가 .dmp인 미니덤프와 _sidecar.json 메타데이터가 쌍으로 끝없이 생성된다. 한 사용자는 하루 만에 이 폴더가 4.9GB, 파일 5만 4504개까지 불어났다고 전했고, 조사 도중에도 파일 수가 5만 3444개에서 5만 4064개, 다시 5만 4504개로 계속 늘어나는 것을 관찰했다. 주목할 점은 이 와중에도 앱 자체는 멀쩡히 동작했다는 것이다. 즉 전면에서 앱이 죽는 통상적인 크래시가 아니라, 백그라운드에서 크래시 리포트가 무한히 축적되는 조용한 디스크 누수에 가깝다.
핸들러가 자기 자신을 덤프하는 루프
여러 제보를 종합하면 원인은 크래시를 수집해야 할 주체인 browser_crashpad_handler 자체가 반복적으로 죽고 되살아나는 데 있다. 최신 덤프 파일에는 핸들러가 남긴 FATAL 메시지가 담겨 있었고, 시스템 진단 로그에도 handler 크래시가 반복 기록됐다. 결과적으로 핸들러가 자기 자신의 크래시를 덤프로 남기는 루프가 형성돼, 정리나 회전(rotation) 없이 pending 폴더가 초당 한 건 수준으로 불어난다. PPID가 1인 핸들러 프로세스 두 개가 동일한 Crashpad 데이터베이스를 물고 돌아가는 모습도 포착됐다. 한 사용자는 59GB에 도달해 파일시스템 한도인 6만 5535개를 넘겼는데도 백그라운드 프로세스가 계속 덤프를 시도하더라고 적었다.핵심 기술적 단서는 한 제보자가 지적한 대목이다. Crashpad에는 오래된 리포트를 솎아내는 프루너(pruner)가 기본 탑재돼 있지만, 이 앱에는 그 정리 로직이 연결돼 있지 않다는 것이다. 핸들러만 배선하고 프루너를 빠뜨리는 구성은 다른 일렉트론(Electron) 기반 앱에서도 보이며, 특히 텔레메트리 전송이 꺼져 있거나 네트워크로 차단된 환경에서는 업로드·처리되지 못한 리포트가 pending에 그대로 적체된다. 결국 생성은 되는데 비우는 쪽이 없으니 디스크만 쌓인다.
경로가 둘, 규모는 테라급에 근접
문제를 추적하기 까다롭게 만드는 요소 중 하나가 데이터 경로가 여러 벌이라는 점이다. 초기 보고는 com.openai.codex/web/Crashpad/pending 아래에서 폭증했지만, 통합된 ChatGPT/코덱스 데스크톱 빌드에서는 Codex/Crashpad/pending라는 새 경로가 문제를 일으켰다. 후자에서는 약 100GB, 파일 약 100만 개까지 치솟아 디렉터리를 나열하는 것만으로도 8초 안에 끝나지 않을 만큼 느려졌다는 사례가 나왔다. 개별 파일은 json이 2바이트대, 덤프가 150KB 수준으로 작아서, 거대한 몇 개가 아니라 수십만 개의 자잘한 파일이 용량을 만든다. 33.4GiB 중 23.3GiB가 사흘 만에 생겼다는 측정도 있었다.되돌리기 어려운 결함과 임시방편
빌드 롤백으로 피하기도 어려워 보인다. 한 사용자가 공식 빌드 5538(26.715.31251)과 5650의 핸들러를 비교했더니 둘 다 크로미움 150.0.7871.124를 쓰고 Mach-O UUID와 서명되지 않은 코드 영역의 SHA-256 해시까지 동일했다. 즉 5538로 내려도 같은 실패가 재현될 가능성이 크다. 브라우저 백엔드를 끄거나 config.toml에서 browser/chrome 번들을 비활성화하고 BROWSER_USE_AVAILABLE_BACKENDS를 비워도 재시작 후 덤프 증가가 멈추지 않았다. 앱 번들 안의 핸들러는 sudo로도 수정이 막혔다(Operation not permitted). macOS 26.5 이상에서 해소된다는 코멘트가 있었으나, 그것이 OS 차원의 수정인지 앱 업데이트가 함께 필요한지는 확인되지 않았고, 최신 빌드(26.818.41509 등, 크로미움 151.0.7922.170)에서도 여전히 재현된다는 보고가 이어졌다.당장의 회피책으로 pending 폴더를 비우는 방법이 공유됐지만, 삭제 직후 새 덤프 쌍이 곧바로 다시 생겨 근본 해결은 아니다. 15분마다 폴더를 비우는 cron 작업, 혹은 Crashpad 데이터베이스를 읽기 전용·불변(immutable)으로 만들어 쓰기를 차단하는 방식이 효과를 봤다는 사례가 있다. 다만 후자는 비상 제동으로만 다뤄야 한다는 경고가 뒤따랐다. 폴더를 영구 읽기 전용으로 두면 정상적인 크래시 리포트 기록까지 막혀 정작 유지보수 담당자가 필요로 하는 신호가 사라지기 때문이다. 앱 상태 디렉터리 전체를 지우는 것도 권장되지 않았다.