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

다른 탭이나 창에서 로그인했습니다. 세션을 새로 고치려면 다시 로드하십시오. 다른 탭이나 창에서 로그아웃했습니다. 세션을 새로 고치려면 다시 로드하십시오. 다른 탭이나 창에서 계정을 전환했습니다. 세션을 새로 고치려면 다시 로드하십시오. 알림 해제

{{ message }}

Repository navigation

CLI: make daemon_auto_start opt-in — a persistent, self-updating background daemon shouldn't be the default #48195

CLI — 0.157.0, installed via npm install -g @openai/codex, Linux (WSL2)

어떤 기능을 보고 싶으신가요?

CLI에 대해 daemon_auto_start opt-in (기본값 false)을 설정하거나, 최소한 켜기 전에 한 번 물어봐 주십시오.

0.157.0 버전부터는 대화형 codex 세션을 열기만 해도:

• 영구적인 백그라운드 데몬(codex app-server --managed-daemon)을 시작합니다. 이는 TTY가 없는 자체 세션에서 실행되며, 모든 Codex 창이 닫힌 후에도 계속 실행됩니다 (PID 1로 재부모화됨). codex app-server daemon stop을 하거나 재부팅될 때까지 작동합니다.
• 전체 플랫폼 패키지(~374 MB: codex, codex-code-mode-host, 번들된 bwrap/zsh/rg)를 ~/.codex/packages/app-server-daemon/releases/<version>/에 복사합니다. 이는 npm이 방금 설치한 것과 바이트 단위로 동일하며, 해당 복사본에서 데몬을 실행합니다. 그 이후로는 백엔드의 버전이 제가 패키지 관리자로 설치한 CLI 버전과 분리됩니다.

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

만약 기본값으로 유지한다면, 최소한 다음 조치를 취해 주십시오:

• 마지막 클라이언트가 연결을 끊으면 자동 시작된 데몬을 종료합니다;

데몬 비활성화 중 발견된 버그: codex app-server daemon stop은 앱-서버를 중지시키지만, 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 세션에서 더 이상 데몬을 생성하지 않습니다.

@Yihua-Liu-1997 이 문제를 보고해 주셔서 감사합니다. 저도 직접 확인했습니다... 작은 버전 번호 증가만으로 갑자기 미스터리 서버와 프로세스를 생성해서는 안 됩니다. 사용자들에게 미리 알려줘야 합니다...

tagor, Flaviu Tamas, Felipe Lopes, Josh Triplett, BigBoyDevBox, Kamil Mielnik, Mikhail, Ayanami Kaine, Mike Elliott, Alexander Williamson 및 12명이 반응했습니다.

CLI가 자체를 관리되는 릴리스 디렉터리로 복사하고 백그라운드 업데이트기가 그 사본을 교체할 수 있게 되면, 나중 턴에 서비스를 제공하는 프로세스는 더 이상 사용자가 명시적으로 설치하거나 호출한 아티팩트가 아닐 수 있습니다.

저는 데몬이 각 클라이언트 연결마다 다음 내용을 포함하는 작은 실행 영수증(execution receipt)을 노출하도록 만들 것을 제안합니다:

• 데몬 바이너리가 패키지 관리자 상태와 독립적으로 변경되었는지 여부;
• 데몬이 이전 세션의 환경에서 상속되었는지 여부.

강력한 회귀(regression)는 다음과 같이 시작될 것입니다. 데몬을 환경 A에서 실행하고, 환경 B에서 연결하며, 설치된 CLI를 업데이트하고, 클라이언트가 포그라운드 CLI 버전으로부터 추론하는 대신 해당 턴에 권위 있는 데몬 세대/바이너리/환경이 무엇인지 정확히 볼 수 있는지 확인합니다.

문서에 언급된 전체 호스트 파일 시스템에 대한 완전한 읽기/쓰기 액세스 요청 때문에 저는 hardened Raspberry Pi에서 codex-cli를 실행하고 SSH로 접속하고 있습니다.

제가 볼 수 있는 데몬은 실행되고 있지 않습니다. 지난주 버전 v0.160.0입니다.

지원되는 옵트아웃(opt-out)은 여전히 공식 설정 참조 문서에서 보이지 않습니다. 제가 오늘 전체 페이지를 가져왔는데, CLI 자체의 check_for_update_on_startup을 설명하면서도 daemon_auto_start 행이 없습니다. 0.157.0 릴리스 노트는 이 변경 사항에 대해 여전히 한 문장으로만 언급합니다—'서버 설정이 호환되지 않을 때 복구 옵션을 제공하며, 적격한 대화형 세션에 대한 자동 백그라운드 서버 시작을 활성화함'—지속적인 프로세스(persistent process), 관리되는 패키지 사본(managed package copy) 또는 시간별 업데이트기(hourly updater)의 이름은 언급하지 않습니다. #40969는 여전히 업데이트기의 60초 동안의 드레인(drain) 후 SIGKILL에 대한 이슈로 열려 있습니다.

@aetherxeg-source의 execution-receipt 제안이 여기서 유용한 경계입니다: 클라이언트 버전, 데몬 바이너리 다이제스트/세대(digest/generation), 업데이트기 상태, 그리고 상속된 환경 생성. @alexklibisz의 새로운 환경 보고서가 마지막 필드를 구체화합니다. 저는 데몬을 실행하는 대신 현재 문서를 추적하고 소스 스레드를 추적했습니다: 소스 흔적: https://bokonon.ai/notes/2026-10-12-codex-omits-daemon-auto-start/

와우. 그래서 저는 codex cli를 설치했는데, 며칠이 지나자 백그라운드에서 1.3GB의 업데이트가 다운로드된 것을 발견했습니다. 이 기능은 기본적으로 비활성화되어야 합니다.