Codex 데스크톱 크래시 덤프가 계속 쌓일 때: 디스크 용량 확인·정리법

Codex 데스크톱을 쓰는데 Mac 저장 공간이 이유 없이 줄어든다면, 가장 먼저 Crashpad의 pending 폴더 크기를 확인해 보세요. 2026년 6월부터 10월까지 openai/codex 이슈 #25921을 비롯한 여러 GitHub 보고에서, macOS용 Codex 데스크톱 앱이 앱은 정상적으로 쓸 수 있는 상태인데도 백그라운드에서 크래시 덤프를 계속 만들어 수 GB에서 수백 GB까지 디스크를 채운 사례가 나왔어요. 이 글은 2026년 10월 기준으로 공개된 이슈 원문을 바탕으로 덤프가 무엇인지, 어디에 쌓이는지, 어떻게 확인하고 정리하는지, 그리고 정리할 때 조심할 점을 정리해요. 대상은 macOS 사용자이며, 수치는 모두 개별 보고자의 측정값이라 모든 사용자에게 같은 규모로 일어난다는 뜻은 아니에요.

크래시 덤프와 Crashpad는 무엇인가요

크래시 덤프(minidump)는 프로그램이 비정상 종료될 때 그 순간의 상태 일부를 파일로 저장한 기록이에요. Chromium 계열 앱이 쓰는 Crashpad는 공식 설계 문서에서 사후 크래시 리포트를 수집·저장·전송하는 라이브러리라고 설명해요. 별도 프로세스인 핸들러가 충돌한 프로세스의 상태를 스냅샷으로 떠서 데이터베이스에 덤프로 기록하고, 설정에 따라 수집 서버로 업로드하는 구조예요. 업로드를 기다리는 덤프가 모이는 곳이 바로 pending 폴더예요.

정상이라면 이 폴더는 가끔 생기는 충돌 기록 몇 개만 담고 있어야 해요. 같은 설계 문서는 데이터베이스가 설정 가능한 개수와 최대 총용량 안에서 덤프를 보관하도록 설계됐다고 적고 있어요. 그런데 Codex 데스크톱 보고 사례에서는 덤프가 업로드되거나 정리되지 않은 채 끝없이 늘었어요. 보고자들이 요청한 해결책도 대부분 개수·용량 상한이나 보관 기간(TTL)을 두라는 내용이었어요.

이번 문제에서 특이했던 점

여러 보고자가 덤프 파일 안을 들여다본 결과, 충돌하고 있던 것은 Codex 앱 화면이 아니라 크래시 리포터 자신이었어요. 이슈 #36982와 이슈 #52194에는 browser_crashpad_handler가 시작 직후 exception_handler_server.cc:76의 검사(mach_port_request_notification: invalid capability)에서 실패하고, 다시 실행되며 자기 자신의 충돌을 덤프로 남기는 반복이 기록돼 있어요. 그래서 사용자는 앱이 멀쩡하다고 느끼는 동안 디스크만 조용히 줄어드는 상황을 겪었어요. 일부 보고자는 Codex의 셸 도구로 실행한 하위 프로세스가 실패한 시점과 첫 덤프 시각이 일치했다고 적었지만, 이것이 확정된 원인이라고 OpenAI가 밝힌 것은 아니에요.

보고된 규모: 얼마나 빨리 쌓였나

아래 표는 이번 세션에서 직접 읽은 이슈 원문의 측정값만 옮긴 거예요. 사용 환경·앱 버전·측정 방식이 모두 달라 서로 비교하기보다 규모를 가늠하는 용도로 보세요.

표에서 보듯 폴더 경로가 시기에 따라 달라요. 6월 보고는 com.openai.codex/web/Crashpad 아래였고, 8월 이후 보고는 Codex/Crashpad 아래였어요. 8월 보고에는 앱이 ChatGPT.app 이름으로 설치돼 있었지만 번들 ID는 com.openai.codex였다는 기록도 있어요. 따라서 한 경로만 확인하고 안심하지 말고 두 경로를 모두 살펴보는 것이 좋아요. 덤프 하나는 보고에 따라 약 82KB에서 175KB였고, 짝을 이루는 sidecar JSON은 수 바이트에서 24바이트 정도였어요. 파일 하나는 작지만 초당 한 개씩 쌓이면 하루 수 GB가 돼요.

Codex 데스크톱 디스크 용량 확인 방법

먼저 Mac 전체 상황을 봐요. Apple 지원 문서에 따르면 macOS Ventura 13 이상에서는 Apple 메뉴의 시스템 설정 → 일반 → 저장 공간에서 항목별 사용량을 볼 수 있어요. 앱 데이터 폴더의 크래시 덤프는 보통 특정 범주에 속하지 않아 '시스템 데이터'처럼 넓은 범주로 잡히기 쉬워요. 시스템 데이터가 비정상적으로 크다면 아래 단계로 폴더를 직접 확인해 보세요.

1. 1

   터미널에서 폴더 크기를 재요

   du -sh "$HOME/Library/Application Support/Codex/Crashpad/pending"와 du -sh "$HOME/Library/Application Support/com.openai.codex/web/Crashpad/pending"를 각각 실행해요. 폴더가 없다는 메시지가 나오면 해당 경로는 쓰지 않는 버전이에요.

2. 2

   파일 수를 세요

   find "$HOME/Library/Application Support/Codex/Crashpad/pending" -type f | wc -l로 개수를 확인해요. 수십 개 수준이면 일반적인 충돌 기록일 수 있지만, 수천에서 수십만 개라면 반복 생성을 의심해요.

3. 3

   계속 늘어나는지 확인해요

   1~2분 간격으로 같은 명령을 다시 실행해 개수가 늘어나는지 봐요. 보고 사례에서는 앱을 켜 둔 동안 초당 약 1개씩 늘었어요. 늘지 않는다면 과거에 쌓인 잔여물일 가능성이 커요.

4. 4

   버전과 실행 중인 핸들러를 기록해요

   앱 메뉴의 'Codex 정보'에서 버전을 적고, 활동 모니터에서 browser_crashpad_handler를 검색해 여러 개가 오래 실행 중인지 봐요. 10월 보고에서는 디스크에서 사라진 옛 프레임워크 버전의 핸들러가 두 달 가까이 남아 있었어요.

정리하는 순서와 주의할 점

보고자들의 공통된 경험은 pending 폴더 안의 파일을 지우면 공간이 바로 돌아온다는 거예요. 6월 원 보고자는 4.9GB가 6.4MB로 줄었다고 적었어요. 다만 덤프를 만드는 반복이 멈추지 않으면 다시 쌓이므로, 정리와 원인 차단을 함께 해야 해요. #52194 보고자는 OpenAI 지원팀이 앱을 닫은 상태에서 pending 리포트를 지우고, 앱을 최신으로 유지하고, 측정값과 함께 GitHub 이슈를 남기라고 안내했다고 적었어요.

1. Codex(또는 ChatGPT) 앱을 완전히 종료해요. 메뉴 막대와 Dock에서 실행 중이 아닌지 확인해요.
2. Finder에서 이동 → 폴더로 이동을 열고 위의 pending 경로를 입력해, 그 폴더 안의 파일만 지워요. 상위 Crashpad 폴더나 ~/.codex 폴더는 건드리지 않아요.
3. 파일이 수십만 개라 휴지통 이동이나 rm 명령이 실패하면, #36982 보고자가 쓴 find "$HOME/Library/Application Support/Codex/Crashpad/pending" -type f -delete처럼 파일을 하나씩 지우는 방식이 진행되면서 공간을 조금씩 돌려줘요. 경로를 정확히 입력했는지 꼭 다시 확인하세요.
4. Finder로 지웠다면 휴지통을 비워야 실제 공간이 돌아와요. Apple 문서도 휴지통을 비우기 전에는 공간이 확보되지 않는다고 안내해요.
5. Mac을 재부팅한 뒤 앱 업데이트를 확인하고, 앱을 실행한 상태에서 몇 분 동안 파일 수가 다시 늘어나는지 지켜봐요.

재부팅·업데이트로 멈춘 사례와 멈추지 않은 사례

효과는 사례마다 달랐어요. 10월 #52194 보고자는 남아 있던 Codex 관련 프로세스를 모두 종료해도 덤프가 계속 생겼지만 macOS를 재부팅하자 0개로 멈췄다고 적었어요. 8월 #36982의 한 댓글은 업데이트 후 앱을 완전히 다시 실행하자 증가가 멈췄다고 했고, 다른 댓글은 업데이트 후에도 초당 약 1개씩 다시 쌓였다고 했어요. 6월 보고에서는 재설치도 효과가 없었어요. Codex 기여자 한 명은 더 최신 macOS(26.5)에서는 해결된 것 같다고 댓글을 남겼지만 확정적인 표현은 아니었어요. 그래서 어떤 방법을 쓰든 '정리 → 재시작 → 몇 분 뒤 다시 세기'로 실제 결과를 확인하는 것이 중요해요.

덤프에 담길 수 있는 민감 정보

크래시 덤프를 버그 리포트에 첨부하고 싶을 수 있지만 조심해야 해요. Crashpad 설계 문서의 개인정보 항목은 충돌한 프로세스 메모리의 임의 내용, 예를 들어 사용자 ID와 비밀번호, 카드 정보, URL 등이 담길 수 있다고 명시해요. Codex 이슈 보고자들도 덤프에 메모리·로컬 경로·전체 프로세스 환경 변수가 들어갈 수 있어 공개 첨부를 피했다고 적었어요. AI 코딩 도구는 터미널 명령과 프로젝트 파일, 때로는 API 키가 든 환경 변수를 다루기 때문에 위험이 더 커요. 공개 이슈에는 파일 개수·용량·앱 버전·macOS 버전 같은 측정값만 남기고, 덤프 원본은 공식 지원 채널이 안전한 업로드 경로를 안내할 때만 제공하세요.

공식 수정 여부를 확인하는 방법

2026년 10월 18일 확인 시점에 원 이슈 #25921과 #36982는 열려 있는 상태였고, #52194는 보고자가 재부팅으로 해결됐다며 스스로 닫은 상태였어요. 이슈가 닫혔다고 해서 공식 수정이 배포됐다는 뜻은 아니므로, 닫힌 이유를 함께 읽어야 해요. 수정 여부는 openai/codex 저장소의 릴리스 노트에서 Crashpad·크래시 리포트·저장 공간 관련 항목을 찾고, 해당 이슈에 OpenAI 관계자의 답변이나 연결된 수정 커밋이 있는지로 판단해요. 앱을 업데이트한 뒤에는 위의 파일 수 확인을 한 번 더 하는 것이 가장 확실한 검증이에요.

AI 코딩 도구 관련 이슈는 개발자 커뮤니티와 텔레그램 채널에서 먼저 퍼지는 경우가 많아요. 더따리 AI 텔레그램 트렌드와 블로그 트렌드 대시보드에서 비슷한 버그 보고나 업데이트 소식이 화제가 되는지 살펴보고, 사실 여부는 위처럼 이슈 원문과 릴리스 노트로 교차 확인하세요.

페이지 참고

트렌드theddari.com›트렌드텔레그램 · AIAI 채널 실시간 포스팅 피드

페이지 참고

트렌드theddari.com›트렌드블로그 대시보드네이버 블로그 활동량 랭킹

AI 코딩 앱 저장 공간 점검 체크리스트

이런 문제는 Codex 데스크톱에만 국한되지 않아요. AI 코딩 앱은 로그·캐시·세션 기록·작업용 복사본 같은 데이터를 로컬에 많이 남기는 편이고, 이번 이슈들처럼 크기 상한이 없는 폴더가 있으면 어느 순간 디스크를 크게 차지할 수 있어요. 한 달에 한 번 정도 아래 항목을 점검하면 갑작스러운 디스크 부족을 미리 막을 수 있어요.

• 시스템 설정 → 일반 → 저장 공간에서 시스템 데이터가 갑자기 커지지 않았는지 확인해요.
• 사용 중인 AI 코딩 앱의 Application Support 폴더와 홈 폴더의 설정 폴더(예: ~/.codex) 크기를 du -sh로 기록해 두고 지난달과 비교해요.
• Crashpad pending처럼 업로드 대기 크래시 리포트 폴더에 파일이 수천 개 이상 쌓였는지 봐요.
• 앱 업데이트 뒤에는 앱을 한 번 완전히 종료하고 다시 실행해, 옛 버전 헬퍼 프로세스가 남지 않게 해요.
• 정리 전에는 무엇을 지우는지 경로를 확인하고, 설정·세션·작업 결과가 든 폴더는 백업 없이 지우지 않아요.

정리하면, Codex 데스크톱 크래시 덤프 문제는 앱이 겉보기에 정상이어서 늦게 발견되기 쉬운 문제예요. pending 폴더 크기와 파일 수를 재고, 앱을 끈 상태에서 그 안의 파일만 지우고, 재부팅·업데이트 후 다시 늘어나는지 확인하는 세 단계를 기억해 두세요. 덤프 원본은 민감 정보가 담길 수 있으니 공개하지 말고, 수정 여부는 이슈 상태와 릴리스 노트로 직접 확인하는 습관을 들이면 비슷한 문제가 다시 생겨도 빠르게 대응할 수 있어요.