Codex 로그 버그, 로컬 SSD에 연 640TB 쓰기 만들 수 있음

• Codex가 로컬 SQLite 피드백 로그에 너무 많이 쓰고 있다는 GitHub 이슈가 올라옴

  • 문제 파일은 ~/.codex/logs_2.sqlite, logs_2.sqlite-wal, logs_2.sqlite-shm
  • 제보자 머신에서 약 21일 가동 후 메인 SSD 쓰기량이 37TB까지 올라갔고, 프로세스·파일 단위 확인 결과 Codex SQLite 로그가 주요 지속 writer로 지목됨

• 이 속도를 1년으로 늘리면 숫자가 꽤 살벌함

  • 대략 640TB/year, 즉 1TB SSD 기준 연간 640회 전체 드라이브 쓰기 수준
  • 일부 소비자용 SSD 보증 내구성이 600TBW 근처라서, 최악의 경우 1년 안에 보증 쓰기 수명을 거의 다 먹을 수 있다는 계산임

• retained DB 크기만 보면 문제가 작아 보일 수 있는데, 실제론 쓰기 증폭이 핵심임

  • 15초 샘플에서 약 36,211행이 삽입됐지만 retained row count는 거의 그대로였다고 함
  • 즉 로그를 넣고, 인덱싱하고, WAL에 쓰고, 다시 pruning하는 루프가 계속 돌면서 디스크 쓰기량만 커질 수 있음

• 가장 큰 원인 후보는 SQLite 피드백 로그 sink의 global TRACE 기본값임

  • 코드상 Targets::new().with_default(Level::TRACE)가 사용된 것으로 지목됨
  • 이러면 Codex 자체 로그뿐 아니라 dependency/internal 로그, raw websocket/SSE payload까지 기본적으로 TRACE 수준에서 저장될 수 있음

• 샘플 기준으로 줄일 수 있는 로그가 대부분을 차지함

  • TRACE 로그만 retained bytes의 70.7%였음
  • codex_otel.log_only와 codex_otel.trace_safe가 추가로 25.3%를 차지해서, 이 세 범주만 필터링해도 샘플 기준 약 96%의 retained log bytes를 줄일 수 있다고 주장함

• 실제 예시도 꽤 잡음에 가까움

  • inotify 이벤트로 ld.so.cache OPEN이 128,764회, locale.alias OPEN이 37,982회, passwd OPEN이 23,843회 기록됨
  • tokio-tungstenite 내부 poll_next, read, WouldBlock, WebSocket opcode 같은 저수준 이벤트도 수천 회 단위로 남음

• 제안된 수정 방향은 ‘로그 끄기’보다 ‘기본 필터링을 sane하게’임

  • SQLite 피드백 로그 sink에 global TRACE를 기본으로 쓰지 말 것
  • target=log, hyper_util, tokio-tungstenite, inotify spam, 저수준 OpenTelemetry SDK 로그의 threshold를 올리거나 버릴 것
  • raw websocket/SSE payload 전문 대신 이벤트 종류, duration, 성공·실패, token usage, payload byte length 같은 요약만 저장할 것
  • per-thread cap만으로는 부족하니 전역 DB 크기·쓰기 cap을 둘 것

• 관련 이슈도 이미 여러 개라서 단발 제보로 보기 어려움

  • SQLite WAL write, logs_N.sqlite 무한 성장, idle Codex process의 heavy I/O, WSL2 100% disk active time, goals_1.sqlite write amplification 등이 함께 언급됨
  • 개발자 도구가 ‘관측성’을 넣다가 로컬 머신 자원을 조용히 태우는 전형적인 사고 패턴임

---

기술 맥락

• 여기서 기술적 선택은 피드백 로그를 SQLite에 얼마나 자세히 남길지예요. 왜냐하면 피드백 디버깅에는 상세 로그가 필요하지만, global TRACE를 기본값으로 두면 사용자 머신의 디스크가 로그 저장소처럼 쓰이기 때문이에요.

• SQLite WAL은 작은 로컬 DB에 편한 선택이지만, 계속 삽입하고 지우는 workload에서는 쓰기량이 생각보다 커질 수 있어요. 특히 retained row count가 유지돼도 WAL 기록, 인덱스 갱신, pruning이 반복되면 SSD 입장에선 계속 쓰는 거거든요.

• 제보자가 제안한 방향은 기능을 없애자는 게 아니라 저장 대상을 좁히자는 쪽이에요. raw websocket/SSE payload나 dependency TRACE 로그 대신 이벤트 종류, 시간, 성공 여부, 토큰 사용량 같은 요약만 남기면 디버깅 가치는 남기고 I/O 비용은 크게 줄일 수 있어요.

• 이 문제는 Codex만의 특수한 버그라기보다 에이전트형 개발 도구 전반의 운영 이슈에 가까워요. 장시간 떠 있는 CLI나 데스크톱 앱은 로컬 로그 정책도 제품 품질의 일부로 봐야 해요.