Codex CLI가 스스로 업데이트하는 상주 백그라운드 데몬을 기본값으로 설치합니다

Codex CLI installs a persistent, self-updating background daemon by default

github.com/openai ▲ 450 댓글 230 whimblepop

요약

Codex CLI 0.157.0이 창을 닫아도 남는 데몬과 자동 업데이터를 기본으로 띄웁니다.

한 사용자가 오픈AI의 Codex 저장소에 올린 이슈입니다. npm으로 설치한 Codex CLI 0.157.0을 리눅스(WSL2)에서 실행하자 데몬(백그라운드에서 계속 도는 프로그램)이 생겨 세션이 끝나도 남았습니다. 그래서 daemon_auto_start 설정을 기본으로 꺼 달라고 요청했습니다.

왜 중요한가

  • 사용자가 패키지 관리자로 고른 버전과 실제로 도는 데몬의 버전이 서로 달라질 수 있습니다.
  • 데몬이 처음 실행한 세션의 환경 변수를 물려받아 GH_TOKEN 같은 비밀값이 다른 작업으로 새어 나간다는 보고도 나왔습니다.
  • 이 설정은 공식 설정 문서에 없고 릴리스 노트에도 한 문장뿐이라 사용자가 알아채기 어렵습니다.

핵심 내용

  • 대화형 codex 세션을 시작하면 codex app-server --managed-daemon이 떠서 창을 닫아도 계속 실행됩니다.
  • 약 374MB짜리 패키지 전체를 ~/.codex/packages/app-server-daemon/ 아래에 복사해 그 사본으로 데몬을 돌립니다.
  • 별도 업데이터(pid-update-loop)가 매시간 업데이트를 확인하고 백엔드를 재시작해 진행 중인 작업이 끊길 수 있습니다.
  • codex app-server daemon stop으로 데몬을 멈춰도 업데이터는 그대로 남는 버그도 함께 보고됐습니다.
  • 작성자는 기능 끄기와 데몬·업데이터 종료, 패키지 폴더 삭제로 이어지는 우회법을 올렸고, 오픈AI 관리자의 답변은 아직 없습니다.

HN 반응

  • 여러 이용자가 설정 파일이나 명령으로 데몬을 끄는 법을 공유하며, Codex를 다 끈 뒤에도 남는 프로세스는 지나치다고 비판했습니다.
  • 옛 버전이 쌓여 12GB를 차지했다는 경험담에, 다른 코딩 에이전트 도구들도 뒷정리를 못 한다는 공감이 이어졌습니다.

댓글

30개 표시 · 전체 230개
  1. whimblepop HN

    이걸 끄는 설정이 문서화돼 있지는 않지만, 지금은 기능 플래그 뒤에 숨어 있습니다. ~/.codex/config.toml[1]에서 바꿔 주시면 됩니다.

      [features]
      daemon_auto_start = false
    

    시작할 때 ~/.codex에 쓰는 파일도 몇 개 있습니다. pid 파일, 락 파일 같은 것들입니다. 이 파일들을 지우고 /dev/null로 가는 심볼릭 링크로 바꾼 다음, chattr +i 같은 걸로 쓰기 불가로 표시해 두면 됩니다. 나중에 기능 플래그가 없어지더라도 백그라운드 데몬이 시작하자마자 죽을 겁니다.

    --

    1: https://github.com/openai/codex/blob/0c329ad2c9d5a2592128a1d536c66e16f9397e46/codex-rs/core/config.schema.json#L869

  2. pilooch HN

    맞습니다, 기본값은 꺼짐이어야 합니다. 데몬은 pi나 pi-durable 같은 커스텀 하니스처럼 데몬 서버 위에 앱을 만들 때 유용합니다.

  3. whimblepop HN

    ACP가 LLM 에이전트를 헤드리스로 쓰기에 부족한 점이 뭔가요? 그걸 고치거나, 플러그인식 LLM 에이전트를 위해 설계된 다른 프로토콜로 표준을 모으는 쪽이 더 낫다고 봅니다(ACP는 적어도 처음에는 IDE에서의 페어 프로그래밍 쪽에 더 맞춰져 있었던 것 같네요).

  4. Twirrim HN

    무슨 이유에선지 데몬이 시작을 거부하고 Codex가 계속 투덜거렸습니다. 이 데몬이 어디서 튀어나온 건지 궁금했고, 제가 예전에 뭘 놓쳐서 그게 그냥 고장 난 건가 싶었습니다.

  5. vunderba HN

    네, 진짜 문제는 예전에 없던 기능인데 Codex 0.157.0부터 켜지면서 이런 지속형 쓰레기[1]를 깔아 놓는다는 겁니다. 내 컴퓨터에서 마지막 Codex 인스턴스가 종료된 뒤에도 살아남는데, 정말 역겹습니다.

      codex features disable daemon_auto_start
      codex app-server daemon stop
      pkill -f 'app-server daemon pid-update-loop'
    

    [1] - https://github.com/openai/codex/issues/48195

  6. icantevenhold HN

    옛날 버전들이 쌓여서 제 하드디스크도 가득 차요. 알아보니 시스템 전체에서 12기가바이트쯤 차지하고 있더라고요. 말도 안 돼요, 그냥 하니스일 뿐인데요?

    사람들은 Claude Code가 얼마나 못 만들었는지 투덜대지만, Codex는 어느 면으로 봐도 훨씬 더 나빠 보여요.

  7. InsideOutSanta HN

    제가 써 본 하니스는 전부 뒷정리를 형편없이 합니다. 온갖 찌꺼기를 남겨서, 제 개발용 VM에서는 하루에 한 번 LLM을 돌려 디스크를 훑어보고 남은 쓰레기처럼 보이는 걸 전부 지우게 할 정도예요.

    불을 끄겠다고 방화범을 고용하는 꼴이죠.

  8. cstever HN

    파일 지우는 데 LLM을 돌린다니 과하다 싶은데요. cron 작업으로는 안 되나요? 아니면 찌꺼기가 아무 데나 흩어져 있는 건가요? 그렇다면 소프트웨어를 엉망으로 만든 건데, 그러면 LLM이 내놓는 결과물 전반을 다시 생각하게 되고, 그러다 보면 우리가 대체 왜 이러고 있는지 궁금해져요.

    그냥 궁금해서 해 본 말이에요.

  9. dannyw HN

    아, 온갖 임시 파일과 디렉터리를 만드는데, 유닉스 파일시스템 관례대로 제 위치에 만들 때도 있지만 대개는 그렇지 않아요.

  10. judge2020 HN

    "clor.com"을 설치했더니 ghcr에서 도커 이미지를 내려받고는 (제 기억으로는) 오래된 버전이라는 이유로 곧장 버리는 일을 무한 반복하더군요. 일주일 동안 65Mbps로 계속 전송했고, 네트워크 트래픽을 들여다보고서야 하루 수신량이 500GB인 걸 알았습니다.

  11. sroussey HN

    방금 Cursor가 남긴 찌꺼기 20GB를 지웠습니다.

  12. umvi HN

    내 컴퓨터를 부풀리지 않는 컴파일 언어로 잘 설계된 하니스가 나올 날이 정말 기다려집니다. 아마 OpenAI가 아닌 다른 회사가 만들어야 할 겁니다. Codex는 제가 방금 나열한 것과 정확히 정반대니까요.

  13. dummydummy1234 HN

    참고로 Codex는 Rust로 만들었습니다... 말씀에 동의하지 않는다는 건 아니고요.

  14. umvi HN

    아, 요즘 소식을 못 챙겼네요. 걸핏하면 npm을 실행하라고 하길래 아직도 TS인 줄 알았습니다.

  15. Twirrim HN

    그냥 npm을 바이너리 배포 수단으로 쓰는 겁니다. 이유는 모르겠지만요(사용자가 전부 npm을 갖고 있다고 보는 걸까요?).

  16. judge2020 HN

    네, 워낙 어디에나 깔려 있긴 하죠. 게다가 기업들은 보통 npm 미러를 운영해서, 배포가 기존 IT 규정 준수 체계에 그대로 들어맞기도 하고요.

  17. lynx97 HN

    그래서 쓸데없이 거대한 바이너리가 나오죠.

  18. rfgplk HN

    정적 링크를 해서 그래요. 아마 (Rust 개발에서는 흔한 일이지만) 쓸모없는 크레이트도 엄청나게 끌어다 쓰고 있을 거고요. 제대로 만든 정적 링크 하니스는 최대 5MB 정도면 충분합니다.

  19. smartmic HN

    이런 걸 찾았습니다: https://usehax.dev/

    써 보신 분 계신가요?

  20. serf HN

    괜찮아요.

    최소한의 기능만 있고 고집이 좀 센 편이에요. 메모리 서브시스템과는 잘 통합돼 있지 않은데, 그게 애초에 취지이기도 하고요.

    제가 느낀 유일한 진짜 단점은, 마지막으로 만져 봤을 때 제공자의 느린 응답을 아주 못 다룬다는 점이에요. 그래서 로컬에서 돌리는 LLM 상당수는 스트리밍, 비스트리밍, 타이머를 제대로 처리하게 하려면 튜닝을 많이 해야 해요.

    저는 그보다 덜 미니멀한(그래도 꽤 미니멀한) Pi를 더 좋아하지만, 시장이 서로 다르다고 생각해요.

    hax는 제 OpenBSD 노트북에 잘 맞았어요. Pi와 그 파생물은 암묵적으로 BSD와는 호환이 안 되는 편이라서요.

  21. OleksandrC HN

    (제작자가 지나가다 답니다) 겪으신 문제를 저장소에 이슈로 올려 주실 수 있을까요? 저는 llama.cpp로 로컬 모델(Qwen, Ornith, Gemma, Muse Glimmer)을 꽤 테스트해 봤는데 전부 잘 돌아갔습니다. 자세한 내용이 있으면 도움이 될 겁니다.

    Codex 사용자분들께 짧게 하나만 더 말씀드립니다. hax는 이미 인증된 codex 토큰을 쓸 수 있어서 codex-cli를 그대로 대체해 바로 쓸 수 있습니다. 그래서 써 보기가 아주 쉽고, 사실상 설정이 전혀 필요 없습니다.

  22. rfgplk HN

    그냥 직접 하니스를 만드세요. 아이러니하게도 Codex와 Claude 둘 다 형편없습니다.

  23. theowaway213456 HN

    Claude 구독을 쓸 수 있는 하니스를 대체 어떻게 만든다는 거죠? 앤트로픽 이용약관상 허용되지 않고 계정이 정지될 수도 있는 줄 알았는데요?

  24. pugz HN

    Amp가 최근에 해냈습니다. Claude Agent SDK를 쓰기만 하면 허용되는 모양입니다. https://ampcode.com/news/use-your-claude-plan

  25. colinmarc HN

    다른 하니스에서 시스템 프롬프트를 살짝 바꾸면 쉽게 우회됩니다. 문자열 매칭과 블랙리스트를 쓰거든요.

    https://x.com/FlorianKluge/status/2041855675295318039

    (이게 이용약관 위반인지는 분명하지 않습니다.)

  26. sroussey HN

    그건 다른 얘기죠.

  27. fasterik HN

    지금 요금으로 토큰당 비용을 내야 한다면 AI를 안 쓸 사람이 많을 거라고 생각해요. 기술적으로는 다른 얘기가 맞지만, 투자금으로 보조받는 구독 요금제에 얹혀 쓰는 우리 대다수에게 "그냥 직접 하니스를 만들어라"는 사실 답이 되지 못해요.

  28. sroussey HN

    저는 만들었는데, 그럭저럭 쓸 만하게 돌아가게 하려면 이상한 일을 많이 해야 했습니다. 평가도 해 봤는데 opencode보다 나은 부분도 있었지만 pi만큼은 아니었어요. 제 목표는 브라우저와 브라우저 기반 LLM에 맞춰 최적화하는 거라서, 웹 컨테이너 안에서 뭔가를 만들거나 적어도 JSON 스키마를 요청해서(a2ui 방식) UI를 생성할 수 있게 하려고요.

  29. nicce HN

    사람들은 Claude Code가 얼마나 못 만들었는지 투덜대지만, Codex는 어느 면으로 봐도 훨씬 더 나빠 보여요.

    그러고 보니 chatgpt.com과 aistudio.google.com도 오랜만에 본 버그투성이 웹사이트 같아요. 왜 항상 LLM 관련된 것들이 이럴까요?

  30. sdcfgy HN

    우리가 회사에서 뽑아낸 LLM 똥 덩어리는 전부 똑같아요.

Hacker News에서 보기 ↗