Codex CLI 0.157.0은 기본적으로 지속적이고 자체 업데이트되는 백그라운드 데몬을 설치합니다

Codex CLI 0.157.0은 기본적으로 지속적인 백그라운드 데몬을 시작하며, 사용자들은 이를 선택 사항으로 만들기를 원합니다

버전 0.157.0부터 대화형 codex 세션을 열면 묻지 않고 지속적이고 자체 업데이트되는 백그라운드 데몬이 시작됩니다. 2026년 9월 25일 사용자 Yihua-Liu-1997이 연 GitHub 이슈 openai/codex#48195는 CLI에서 daemon_auto_start 기능 플래그를 선택 사항(기본값 false)으로 만들거나 최소한 도구가 활성화하기 전에 한 번 묻도록 요청합니다. 이 이슈는 Hacker News에서 599포인트와 292개의 댓글에 도달했으며, 지배적인 반응은 패키지 관리자를 통해 설치된 CLI가 장기 실행되고 자체 업데이트되는 서버 프로세스를 생성해서는 안 된다는 것이었습니다.

리포터의 환경은 Linux(WSL2)에서 npm install -g @openai/codex로 설치된 Codex CLI 0.157.0입니다. 이 이슈에는 CLI, app-server, enhancement 레이블이 붙어 있습니다.

데몬은 리포터가 놀라운 기본값이라고 생각하는 네 가지 작업을 수행합니다

이슈에 따르면 대화형 codex 세션을 여는 것만으로도 다음 모든 작업이 트리거됩니다:

1. 지속적인 백그라운드 데몬을 시작합니다 (codex app-server --managed-daemon). 프로세스는 TTY 없이 자체 세션에서 실행되며 모든 Codex 창이 닫힌 후에도 PID 1로 재부모화되어 codex app-server daemon stop 또는 재부팅할 때까지 계속 실행됩니다.
2. 전체 플랫폼 패키지를 복사합니다 — 약 374MB로 codex, codex-code-mode-host, 번들된 bwrap/zsh/rg를 포함하며 ~/.codex/packages/app-server-daemon/releases/<version>/에 복사합니다. 복사본은 npm이 방금 설치한 것과 바이트 단위로 동일하며 데몬은 해당 복사본에서 실행됩니다. 이 시점부터 백엔드 버전은 사용자가 패키지 관리자로 설치한 CLI 버전과 분리됩니다.
3. 분리된 업데이터를 시작합니다 (codex app-server daemon pid-update-loop) — 시작 후 5분 후에 업데이트를 확인하고 그 후 매시간 새 릴리스를 다운로드하고 백엔드를 다시 시작합니다. 이 재시작은 활성 턴을 종료할 수 있으며, 이는 이슈 #40969에서 추적되는 별도의 문제입니다.
4. 세션을 시작한 환경을 고정합니다. 리포터는 호출마다 HTTPS_PROXY를 설정하는 래퍼를 통해 Codex를 실행합니다. 데몬은 첫 번째 세션의 프록시 변수를 유지하므로 이후 세션이 무엇으로 시작되든 아웃바운드 연결이 해당 프록시를 통해 이동합니다.

리포터는 환경 고정 동작을 이슈 #42457(--remote 모드의 후크가 세션의 cwd가 아닌 데몬의 cwd를 받음) 및 이슈 #37537(app-server 데몬이 생성한 후크가 클라이언트 터미널을 식별할 수 없음)과 연결하며 동일한 근본 원인처럼 보인다고 설명합니다.

리포터의 명시된 기대: CLI 백엔드는 창과 함께 살고 죽어야 합니다

이슈는 명령줄 도구에 대한 최소 놀라움 기본값을 중심으로 요청을 구성합니다:

CLI의 경우 가장 놀라움이 적은 기본값은 백엔드가 창과 함께 살고 죽고, 내가 설치한 바이너리를 실행하며, 백그라운드에서 스스로 업데이트하지 않는 것입니다. 공유되고 자체 업데이트되는 데몬은 Remote Control / 데스크톱 앱에 적합하므로 거기서 또는 사용자가 명시적으로 codex app-server daemon start / bootstrap을 실행할 때 활성화하는 것이 좋습니다.

기본값이 유지된다면 리포터는 두 가지 대안을 요청합니다: 마지막 클라이언트가 연결을 끊으면 자동 시작된 데몬을 종료하고, CLI가 패키지 관리자(npm, brew, pacman)로 설치된 경우 복사하거나 자체 업데이트하지 말고 설치된 바이너리를 실행하십시오. 이러한 요청은 이슈 #41188(외부 관리 app-server 데몬 실행 파일 지원), 이슈 #46468(npm 업데이트가 app-server를 이전 버전으로 남기지만 데몬 업데이트/재시작이 복구를 거부함), 이슈 #48050(Codex 0.157.0이 --no-daemon을 사용하지 않으면 Arch Linux 패키지로 더 이상 시작되지 않음)을 참조합니다.

codex app-server daemon stop은 업데이터를 중지하지 않습니다

이슈는 기능을 끄려고 시도하는 동안 발견된 버그를 보고합니다: codex app-server daemon stop은 app-server를 중지하지만 pid-update-loop 업데이터는 계속 실행되게 둡니다. 리포터는 70초 후에도 여전히 살아 있었고 수동으로 죽여야 했다고 말합니다.

이슈에 문서화된 해결 방법은 다음과 같습니다:

codex features disable daemon_auto_start
codex app-server daemon stop
pkill -f 'app-server daemon pid-update-loop'   # `daemon stop`으로 중지되지 않음
rm -rf ~/.codex/packages/app-server-daemon

플래그를 끄면 새 TUI 세션이 더 이상 데몬을 생성하지 않는다고 리포터는 확인합니다.

다른 플랫폼에서의 확인 및 구성 파일 수정

GitHub 이슈의 댓글 작성자들은 다른 시스템에서도 동작을 확인하고 구성 기반 수정을 지적했습니다.

사용자 tagorr는 Windows 10 LTSC에서 Codex CLI 0.157.0으로 동일한 문제를 보고했으며 config.toml에서 daemon_auto_start = false로 설정하면 해결된다고 말했습니다. tagorr는 또한 두 가지 개선 사항을 제안했습니다: 상승된 권한으로 데몬 시작이 차단될 때 --no-daemon을 요구하는 대신 로컬 모드로 자동 폴백하고, 데몬 자동 시작을 기본값이 아닌 선택 사항으로 만드는 것입니다. 이슈 작성자는 둘 다 작동할 것이라고 답했습니다.

사용자 felipeelopes는 Windows에서 이 버그로 인해 Codex CLI를 사용할 수 없다고 썼습니다. 유지 관리자 역할로 응답하는 것으로 보이는 사용자 megahall은 다음과 같이 썼습니다:

보고해 주셔서 감사합니다. 저도 직접 겪었습니다... 작은 버전 번호 증가에서 사람들에게 사전 경고 없이 갑자기 미스터리 서버와 프로세스를 만들면 안 됩니다...

사용자 kr8vka0z는 이 문제가 해결될 때까지 CLI를 사용할 수 없다고 썼습니다. 사용자 skhaz는 "이 기능을 비활성화하는 것에 +1"을 추가했습니다. 사용자 laurynas-karvelis는 더 직설적이었습니다: "기본적으로 - 악성 코드의 특성입니다. 솔직히 이것이 우연히 이루어졌다고 생각하지 않습니다."

출처 주장: 설치된 CLI 정체성은 데몬 실행 정체성과 다릅니다

사용자 aetherxeg-source의 댓글은 이 문제를 출처 경계 문제로 구성하며 설치된 CLI 정체성 != 데몬 실행 정체성이라고 말합니다. 주장은 CLI가 자신을 관리되는 릴리스 디렉토리에 복사하고 백그라운드 업데이터가 해당 복사본을 교체할 수 있게 되면 이후 턴을 처리하는 프로세스가 더 이상 사용자가 명시적으로 설치하거나 호출한 아티팩트가 아닐 수 있다는 것입니다.

댓글은 데몬이 각 클라이언트 연결에 대해 최소한 client_cli_version + daemon_binary_digest + daemon_generation + updater_state + inherited_environment_generation을 포함하는 작은 실행 영수증을 노출하여 클라이언트가 네 가지 상태를 구분할 수 있도록 제안합니다: 동일한 설치 아티팩트 및 동일한 데몬 세대; 동일한 CLI이지만 다른 데몬 세대; 데몬 바이너리가 패키지 관리자 상태와 독립적으로 변경됨; 데몬이 이전 세션에서 환경을 상속함.

다운스트림 패키저들이 데몬 자동 시작을 비활성화하기 시작했습니다

여러 타사 저장소가 이 이슈를 참조하는 커밋을 추가했으며, 이는 패키저들이 기본값을 재정의해야 할 것으로 취급했음을 나타냅니다. 여기에는 nixvital/ml-pkgs의 "codex: disable daemon auto-start by default"라는 제목의 커밋(2026년 9월 28일), Codex를 0.160.1로 업데이트하고 nix-user-chroot에 대한 샌드박스 패치를 포함하는 dotfiles 커밋(2026년 10월 7일), 공식 릴리스 바이너리에서 Codex CLI를 패키징하는 NixOS 커밋(2026년 10월 10일)이 포함됩니다.

Hacker News에서 논쟁은 "악성 코드 같다"와 "브라우저도 이렇게 한다"로 나뉘었습니다

Hacker News 스레드는 자동 업데이트에 대한 강한 비판과 방어를 모두 표면화했습니다.

비판은 신뢰, 디스크 사용량, 회귀에 집중되었습니다. 사용자 icantevenhold는 이전 버전이 디스크를 채웠다고 보고했습니다: "조사해 보니 제 시스템에서 총 약 12기가바이트를 차지했습니다. 정말 말도 안 된다고 생각합니다. 그냥 하네스인데? 사람들은 Claude code가 얼마나 잘못 만들어졌는지 불평하지만 Codex는 모든 지표에서 훨씬 나쁜 것 같습니다." 사용자 dllu는 데몬의 자동 업데이트가 파일 권한을 깨뜨렸다고 보고했습니다: "자동 업데이트할 때 무작위로 권한을 망치고 .git이 읽기 전용이 되어 목표를 차단했습니다." 사용자 ranger_danger는 간단히 "어떤 서클에서는 이것을 백도어라고 부릅니다."라고 썼습니다. 사용자 soletta는 "Codex를 삭제하고 구독을 취소합니다. 이 중요한 PSA를 강조해 주신 OP님 감사합니다."라고 썼습니다.

방어는 자체 업데이트가 이제 표준이라는 것이었습니다. 사용자 dingaling911은 "이런 것들은 빠르게 움직이므로 자동으로 업데이트해야 합니다. 이것은 이제 일종의 표준입니다. 브라우저도 그렇게 합니다. 하네스가 그렇게 하지 않을 이유가 없습니다."라고 썼습니다. 합법적인 IDE를 만들었다고 말하는 사용자 piker는 의도가 반드시 적대적이지는 않다고 주장했습니다: "보안, 안정성 등이 가장 중요한 합법적인 IDE에서 다양한 업데이트 접근 방식을 고려했으며, 야생에 버그가 있는 애플리케이션을 두는 것은 사용자에게 적대적입니다... 데몬 방식을 고려했지만 결국 모든 부팅 시 하드 업데이트 확인으로 결정했습니다." 사용자 infinite_spin은 맥락이 중요하다고 언급했습니다: "클라이언트를 설치/실행할 때 이런 종류의 것을 기대하지만 NPM을 통해 설치된 CLI가 이렇게 하는 것이 놀라운 이유를 알 수 있습니다."

한 댓글 작성자에 따르면 Claude Code도 유사한 운영 모델을 사용합니다

사용자 timdorr는 이 패턴이 Codex에만 국한된 것이 아니라고 지적하며 "Claude Code와 동일한 운영 모델"이라고 쓰고 ls ~/.local/share/claude/versions/와 ps auxww | grep "claude bg"를 인용하여 이전 버전의 Claude Code 바이너리와 포그라운드에 Claude Code가 없는 여러 실행 중인 백그라운드 작업을 보여줍니다.

Hacker News 스레드에서 문서화된 해결 방법

여러 댓글 작성자가 데몬을 비활성화하는 방법을 설명했습니다.

스토리를 제출한 사용자 whimblepop은 기능을 비활성화하는 설정이 문서화되어 있지 않지만 현재 ~/.codex/config.toml에서 전환할 수 있는 기능 플래그 뒤에 있다고 언급했습니다:

[features]
daemon_auto_start = false

whimblepop은 또한 더 공격적인 접근 방식을 설명했습니다: 데몬은 시작 시 ~/.codex에 pid 파일과 잠금 파일을 쓰며, 이를 삭제하고 /dev/null에 대한 심볼릭 링크로 교체한 다음 chattr +i로 쓰기 불가능하게 표시하여 기능 플래그가 제거되면 백그라운드 데몬이 시작 시 충돌하도록 할 수 있습니다.

사용자 grimgrin은 구성 파일과 셸 함수를 결합한 중복 안전장치 구성을 게시했습니다:

codex() { command codex --no-daemon "${@:-.}" }

사용자 gruntled-worker는 실행 파일을 복사하여 --no-daemon으로 실행할 수 있으며 최근 터미널 UI 변경 사항은 CODEX_TUI_DISABLE_KEYBOARD_ENHANCEMENT=1 및 /tui 명령으로 비활성화할 수 있다고 추가했습니다.

한 댓글 작성자는 환경 상속 문제가 가장 사용자에게 적대적인 부분이라고 주장합니다

사용자 yearolinuxdsktp는 데몬 자체보다 환경 동작을 지적했습니다:

이 기본 변경의 가장 사용자에게 적대적인 측면은 "명령이 실행된 셸 환경에서 실행된다"는 관례/기대를 조용히 깨는 것이라고 생각합니다. 예를 들어 유효한 환경을 확인하는 세션 시작 후크는 앱 서버의 환경에서 실행되므로 실패합니다. 또한 모델 컨텍스트 크기와 같은 거의 모든 -c 인수를 전달하면 데몬 사용을 조용히 중지합니다.

플랫폼별 손상: Windows 콘솔 창 및 상승된 권한

사용자 ilitirit은 Windows에서 도구가 "명령을 실행할 때마다 새 콘솔 창도 실행한다"고 보고하고 --no-daemon으로 비활성화할 것을 조언하며 CLI가 "2주 전만 해도 완벽하게 사용 가능했다"고 덧붙였습니다. GitHub 이슈의 tagorr와 felipeelopes의 Windows 확인은 동일한 플랫폼이 불균형적으로 영향을 받는 것을 지적하며, tagorr는 특히 데몬 시작이 상승된 권한으로 차단될 때 로컬 모드로 자동 폴백을 요청했습니다.

Codex 및 AI 하네스 품질에 대한 광범위한 불만

여러 댓글 작성자는 데몬만이 아니라 AI 코딩 도구의 전반적인 상태를 비판하는 데 스레드를 사용했습니다.

사용자 Alifatisk은 Codex VS Code 확장을 "얼마나 취약한지 미쳤다"고 설명하며 약 일주일 동안 완전히 고장났다가 부분적으로 수정되었고 여러 이슈가 동일한 문제를 추적하며 커뮤니티가 확장을 직접 패치하기 시작했다고 말했습니다. Alifatisk은 확장의 자동 업데이트를 껐다고 썼습니다 — 그렇게 해야 했던 유일한 확장입니다 — 그리고 결론을 내렸습니다: "이제 '빠르게 움직이고 물건을 부수는' 것의 결과를 경험했습니다. 소프트웨어 품질이 나에게 얼마나 중요한지 깨달았습니다."

사용자 esjeon은 "Codex CLI(및 Claude Code)의 품질은 LLM 기반 개발의 현 상태를 정직하게 반영한다고 생각합니다. 미래가 그렇게 유망해 보이지 않습니다."라고 썼습니다. 사용자 compiler-guy는 사용자 경험은 오랜 기간 동안 일관되게 적용된 집중된 취향으로만 개선되며 "아무도 시간을 들이지 않으면 UX는 계속 나빠질 것입니다. 그리고 아무도 그렇게 하지 않는 것 같습니다."라고 주장했습니다. 사용자 Sha1rholder는 인간 테스트가 전혀 이루어지는지 의문을 제기하며 ChatGPT, Codex Desktop 및 Android 앱의 프런트엔드 품질을 "정말 끔찍하다"고 불렀습니다.

패키징 반론: 배포판은 정확히 이것을 방지하기 위해 존재합니다

사용자 thebeardisred는 이 사건이 운영 체제 배포 모델을 입증한다고 주장했습니다: "소프트웨어를 패키징하고 테스트하고 일반적으로 합리적인 기본값을 만들고 이런 장난을 방지하는 사람들이 있습니다." 사용자 AndreasBackx는 재발명에 관한 관련 지적을 했으며 Codex 설치 스크립트가 기존 패키지 관리자를 사용하는 대신 설치를 직접 관리한다고 언급했습니다: "우리는 패키지 관리자를 통해 소프트웨어를 업데이트하는 방법을 알아냈습니다. 업데이트를 계속 확인하는 데몬이 필요하고 패키지 관리자를 우회하는 셸 스크립트가 필요합니까?"

사용자 clutter55561은 구성 대신 격리를 권장했습니다: "그런 것들을 호스트에 절대 설치하지 마십시오. 잠긴 Docker 컨테이너가 최소입니다. 버전을 고정하고 변경 로그를 확인하지 않고 업데이트하지 마십시오." 사용자 umutsevdi는 벤치마킹 중 데몬을 발견하고 정확한 측정을 위해 이러한 도구 주위에 bwrap으로 전환했다고 보고했습니다.

사용자가 이주한 대안

여러 댓글 작성자가 더 가벼운 하네스를 언급했습니다. 사용자 reacharavindh는 hax를 통해 GPT 모델을 사용한다고 설명했습니다. "최소한의 도구를 가진 기본 하네스"로 대부분의 작업에 bash를 사용하고 시스템 프롬프트의 한 줄을 통해 필요에 따라 CLI 도구를 추가합니다. 사용자 sva_는 Pi Coding Agent를 "훨씬 더 가볍고 제 경험상 독점 하네스보다 훨씬 낫다"고 추천했습니다. 사용자 silverbluep는 Codex가 "상태와 구성 데이터를 혼합"하여 nix-darwin 환경에서 선언적 관리를 방해했기 때문에 Codex를 포기했고 이제 opencode를 통해서만 Codex를 사용한다고 말했습니다. 사용자 pkulak은 완화 요인을 언급했습니다: "OpenAI는 적어도 원하는 하네스를 사용하는 것을 괜찮아합니다. 형편없는 자사 하네스는 나쁘지만 탈출구가 바닥을 제공합니다."

이슈가 요청하는 것, 한 줄로

Codex CLI에서 daemon_auto_start를 기본값 false로 만들거나 활성화하기 전에 한 번 묻습니다. 기본값이 유지되면 마지막 클라이언트가 연결을 끊을 때 데몬을 종료하고 CLI가 패키지 관리자로 설치된 경우 복사하거나 자체 업데이트를 중지합니다. 이슈의 마지막 활동인 2026년 10월 12일 현재 이슈는 담당자, 마일스톤, 연결된 풀 리퀘스트 없이 열려 있습니다.