OpenAI Codex, 하루에 최소 5GB씩 Mac 디스크를 잡아먹는다
Codex is EATING my Mac's disk space
Codex Desktop이 macOS의 Crashpad pending 디렉터리에 .dmp와 _sidecar.json 파일을 끝없이 쏟아내며 디스크를 무한정 채우고 있다. 한 사용자는 하루 만에 4.9GB·5만4천 개 파일을, 다른 사용자는 61GB·73만 개 파일을 기록했다. 앱은 멀쩡히 작동하는데도 browser_crashpad_handler가 스스로 크래시를 반복하며 덤프를 생성하는 것으로 보인다. 재설치와 설정 변경도 소용없었고, Crashpad 디렉터리를 읽기 전용으로 잠그는 임시 우회만이 증가를 멈췄다.
여기저기서 같은 증상이 터졌다. 어떤 이는 59GB까지 불어났다고 했고, 다른 이는 "Claude도 Codex도 사용자 컴퓨터를 전혀 존중하지 않는다"고 꼬집었다.
HN 토론
27- jbellis
이건 버그처럼 보이지만, 정상적인 행복 경로의 codex조차도 수 기가바이트의 로그를 생성합니다. OpenAI는 이게 몇 달째 계속되고 있으니 괜찮다고 생각하는 모양입니다.
두 가지가 도움이 됩니다:
1. 파일 시스템 수준 압축. 저는 ZFS를 사용합니다. Btrfs는 동시 Rust 빌드에서 엄청난 경합 문제가 있거든요.
2. sessionwiki(https://github.com/youdie006/sessionwiki) 같은 걸로 오래된 세션을 아카이브하세요. 저는 이걸 제 컨트롤 플레인(https://github.com/BrokkAi/mjolnir/)에 통합했습니다.
- glenngillen
에이전트를 돌리면서 시스템에 디스크 압박이 심하게 걸리고 있었습니다. 두 가지 주요 원인을 발견했습니다:
- 모든 작업에 git worktree를 사용하는 제 접근 방식. 전혀 놀랍지 않게도, 각 worktree에 중복된 빌드 아티팩트가 주범이었습니다. 빌드 관리 방식을 좀 더 효율적으로 바꾸면 제한적인 이득은 있었지만, 결국 특히 큰 저장소 몇 개에서는 동시에 작업하는 기능의 수를 줄여야 했습니다.
- 더 교활한 원인은 제가 생각했던 것보다 더 자주 메모리 한계에 부딪혀 맥이 스왑을 심하게 해야 했던 점입니다. 이게 일어나는 동안에도 시스템은 놀랄 만큼 꽤 성능이 좋았습니다... 그러다가 갑자기 아니게 되더군요. 안타깝게도 제가 알기로 이 상황에서 유일한 "해결책"은 기계를 재시작하는 것입니다. 일단 디스크에 기록된 스왑 공간을 시스템이 회수할 방법이 없습니다. 하루에 몇 번씩 스래싱이 일어난다면(특히 밤새 뭔가를 돌려두면 쉽게 발생하죠) 금방 쌓입니다.
- AgharaShyam
~/.bun/install/cache/@openai 폴더도 살펴보세요.
왠지 제 경우에는 codex와 codex-code-mode-host 바이너리가 각각 약 300MB씩, 총 11개나 따로 있었습니다.