Codex 로깅 버그가 로컬 SSD에 TB 단위 쓰기를 발생시킬 수 있음

~/.codex/logs_2.sqlite, ~/.codex/logs_2.sqlite-wal, ~/.codex/logs_2.sqlite-shm에 Codex가 지속적으로 많은 데이터를 쓰며, 제보자 환경에서 약 21일 업타임 후 메인 SSD 쓰기량이 약 37TB였고 이를 연간 약 640TB로 환산

보존 행 506,149개 대비 AUTOINCREMENT row id가 5,543,677,486까지 증가해, 보존 행과 과거 삽입 row id 사이에 약 10,000배 차이 발생

15초 샘플에서 보존 행 수는 681,774개로 유지됐지만 max row id가 36,211 증가해, 행을 삽입한 뒤 pruning하는 쓰기 증폭(write amplification) 패턴으로 해석

보존 로그 바이트 기준 TRACE가 70.7%, codex_otel.log_only와 codex_otel.trace_safe가 합산 25.3%였고, 주요 소스는 codex_api::endpoint::responses_websocket, codex_otel.log_only, codex_otel.trace_safe, log 등

추정 원인은 SQLite feedback log sink가 Targets::new().with_default(Level::TRACE)로 설치되어 dependency/internal 로그와 큰 raw protocol payload까지 기본 저장하는 구조

제안된 기본 수정안은 전역 TRACE 제거, target=log, hyper_util, tokio-tungstenite internals, inotify spam, low-level OpenTelemetry SDK 로그 임계값 상향, raw websocket/SSE payload 기본 저장 회피, codex_otel.log_only·codex_otel.trace_safe 미러 이벤트 저장 제한, 전역 로그 DB 크기·쓰기 상한 추가

한 로컬 패치 제안은 SQLite feedback log sink 기본 필터를 warn,codex_api=info,codex_app_server=info,codex_core=info,codex_mcp=info,codex_state=info,codex_tui=info로 바꾸는 방식이었고, upstream PR 생성은 GraphQL: ... does not have the correct permissions to execute CreatePullRequest 오류로 차단

macOS 15.7.7, Codex 26.616.51431 환경에서도 MAX(id)=34,277,360 대비 보존 행 31,405개, 60초 샘플 2회에서 약 초당 60 writes 증가 보고

Windows Codex Desktop OpenAI.Codex_26.616.6631.0_x64__2p2nqsd0c76g0 환경에서도 RUST_LOG=warn과 별도 trace 설정 없음에도 codex.exe app-server --analytics-default-enabled가 TRACE 행을 계속 삽입했고, 최근 10분 상위 소스에 log, codex_api::endpoint::responses_websocket, codex_api::sse::responses 포함

임시 완화책으로 WAL checkpoint/truncate 스크립트, Codex 프로세스 종료 후 WAL/SHM 삭제 스크립트, logs 테이블 INSERT를 RAISE(IGNORE)로 막는 SQLite trigger 방식이 공유됐지만, trigger 방식에는 VACUUM의 일회성 대량 쓰기와 향후 Codex 업데이트·마이그레이션과의 충돌 가능성 우려 존재

Codex는 slopware의 악명 높은 사례 중 하나라고 봄
macOS에서 창만 보이게 둬도 스피너 메시지를 표시하느라 GPU를 100% 사용함 MBP M5에서 스피너 메시지만으로 GPU 100% 가 찍히고, 모델을 기다리는 시간 대부분 동안 팬이 크게 돌기 때문에 배터리 사용 시 조심해야 함
이 이슈는 GitHub에 올라온 지 거의 6개월 됐고, 아마 바이브 코딩으로 만든 잡동사니가 출시된 뒤부터였을 것 같음
직접 고치고 싶어도 이유는 모르겠지만 비공개 소스라 불가능함
어떤 모델이 더 나은지, 바이브 코딩이 가능한지 논쟁이 많지만, 자금·인력·모델 역량이 가장 풍부한 회사 중 하나가 바이브 코딩으로 할 수 있는 수준이 이 정도라고 봄
CEO가 이미 “코딩에 집중한다”고 밝힌 상황에서 이런 심각한 실수는 회사 내부에 뭔가 정말 망가졌다는 신호로 보이고, Polymarket에서도 OpenAI가 곧 선도 모델을 낼 거라고 보는 사람이 거의 없음
세상에는 Anthropic의 경쟁자가 필요하기 때문에 비극적임

Claude Code도 바로 옆에 있으니 slopware 사례에서 빼먹으면 안 됨

AI로 10배 생산성이 나오고 AGI나 ASI에 가깝다면, Codex나 Claude Code CLI 같은 제품이 어떻게 아직도 이렇게 형편없을 수 있는지 모르겠음
“에이전트형 AI 혁명”이 이미 이런 문제를 해결했어야 하는 것 아닌가 싶음
설마 내부에서 “처리 중이니 기다려 달라”거나 “너무 힘든 작업”이라고 하고 있진 않을 텐데

기본적으로 모든 걸 오픈소스로 공개하던 조직에서 일할 때, 사이드 프로젝트까지 포함해 뭔가를 비공개로 남기는 이유는 하나뿐이었음. 부끄러움임
아무도 쓰레기 같은 코드베이스의 공개 얼굴이 되고 싶어 하지 않음
그 코드로 터무니없는 가격을 정당화하고 있다면 그 부담은 세 배쯤 커질 것 같음

Codex만이 아니라 macOS의 ChatGPT 앱도 몇 시간 열어두면 시간이 지나며 RAM을 60GB 먹고 다른 앱들을 다 죽임
이해가 안 됨
브라우저에서 Google AI Studio를 쓰려고 해도 CPU를 100% 사용함
결국 모든 걸 직접 앱으로 만들어야 하나 싶음

초창기에는 세상에 ChatGPT의 경쟁자로 Anthropic이 필요하다고 했는데, 이제는 완전히 한 바퀴 돌아옴

모두가 OpenAI를 비판하고 있고 그럴 만하지만, Claude Code와 달리 Codex는 공식적으로 커스터마이즈 가능하다는 점은 상기할 만함: https://github.com/openai/codex
패치하기도 꽤 쉬움

그건 CLI이고, 여기서 말하는 독점 Codex 앱은 아님

충격적임
이슈가 열린 지 일주일 됐는데, 내가 보기엔 OpenAI는 그냥 침묵 중임
이런 판매사들이 이런 문제에 굉장히 민감할 거라고 생각했는데 이해가 안 됨
당연히 GitHub의 잠재 이슈를 감시하고 수정안을 제안하는 여러 에이전트를 붙여놨겠지? …그렇겠지?
자기 도구들을 돌려서 GitHub 이슈를 실시간으로 고치게 하는 건 당연히 사소한 일이어야 할 텐데

지금 우리 회사에서 누군가의 바이브 코딩한 쓰레기가 심각하게 잘못돼서 대형 장애를 붙잡고 있음

이제 망가뜨릴 것도 점점 바닥나고 있음

기술 부채가 없다면 바이브 코딩은 대체로 프로토타이핑에는 유용함
실제 제품에서는 진짜 소프트웨어 엔지니어가 절대 대체되지 않을 것임

약간 주제에서 벗어나지만, 이 회사들은 저장소 루트 폴더를 Claude.md나 copilot.md로 더럽히는 걸 그만둬야 함
한 방에 모여서 docs/llm/* 같은 잘 알려진 폴더 구조를 정해야 함

작년 말 Claude Code가 지연으로 엉망이었을 때 OpenAI는 거의 잡은 승리를 놓쳤음
요즘은 Codex가 시작하자마자 타이핑 지연이 있고, Claude Code는 가끔 멈추긴 해도 대체로 내가 키를 누르면… 말 그대로… 누른 대로 표시됨

내 경우는 정확히 반대임

Claude Code는 거의 못 쓸 수준이라고 느낌
몇 단어 이상 입력할 때는 항상 neovim에서 입력해야 함

이건 사실 아주 전형적인 실수임
모든 것에 추적/디버그 로그를 켠 채 출시한 것인데, 재미있게도 영향이 일반적인 방식으로 나타나진 않음
예전 같으면 개발자가 trace 수준 로깅을 켜서 앱이 재앙적으로 느려지고 다음 업데이트에서 바로 고쳤을 텐데, 이제는 메모리·CPU 속도·디스크 속도가 압도적으로 좋아져서 그런 식으로 바로 드러나지 않는 지점에 온 게 미친 일임

에이전트 작업이 서버 쪽에서 이뤄지니, 얇은 클라이언트가 로컬 리소스를 다 잡아먹어도 된다는 점도 한몫함