오픈AI의 코덱스(Codex) CLI가 0.157.0 버전부터 사용자가 명시적으로 요청하지 않았는데도 백그라운드 데몬을 자동으로 띄우기 시작하면서 논란이 됐다. 깃허브 이슈(#48195)에 따르면 이 버전 이후로는 단순히 대화형 코덱스 세션을 여는 것만으로도 상주형(persistent) 데몬이 실행되고, 이 데몬은 스스로 업데이트까지 수행한다. npm으로 전역 설치해 쓰는 전형적인 CLI 사용자 입장에서는 예고 없이 '정체불명의 서버와 프로세스'가 생겨난 셈이다.
무엇이 바뀌었나
보고자가 지적한 핵심은 기본값의 문제다. CLI 도구에서 가장 덜 놀라운 동작은 백엔드가 창과 함께 생겨나고 사라지며, 사용자가 설치한 바로 그 바이너리를 실행하고, 백그라운드에서 스스로를 업데이트하지 않는 것이다. 공유형 자동 업데이트 데몬은 리모트 컨트롤이나 데스크톱 앱처럼 여러 세션이 하나의 백엔드를 공유하는 환경에서는 합리적일 수 있다. 문제는 이것이 일반 터미널 세션에서도 기본으로 켜져 있다는 점이다. 보고자는 daemon_auto_start 옵션을 기본 비활성화(opt-in)로 돌리거나, 최소한 처음 한 번은 사용자에게 확인을 받아야 한다고 요구했다.
이 변경은 특정 플랫폼에 국한되지 않았다. WSL2 리눅스 환경에서 처음 보고됐지만 윈도우 10 LTSC에서도 같은 증상이 확인됐고, 여러 사용자가 'CLI에 아무것도 입력할 수 없어 사실상 사용 불가능한 상태'라고 토로했다. 작은 패치 버전 숫자가 올라가는 사이에 동작이 이렇게 크게 바뀌었는데도 별다른 고지가 없었다는 점이 불만을 키웠다.
제거 과정에서 드러난 버그
데몬을 끄려는 과정에서 또 다른 문제가 포착됐다. codex app-server daemon stop 명령은 앱 서버 자체는 중단시키지만, PID 갱신 루프를 도는 업데이터(pid-update-loop)는 그대로 살려 둔다. 보고자는 중단 명령을 내린 뒤 70초가 지나도 업데이터가 살아 있어 결국 수동으로 프로세스를 죽여야 했다고 전했다. 즉 공식 중단 절차를 따르더라도 자동 업데이트 구성요소가 완전히 정리되지 않는다는 뜻이다.
현실적인 회피책은 설정 파일을 직접 손보는 것이다. 사용자 설정(config.toml)에 daemon_auto_start = false를 지정하면 새 TUI 세션이 더 이상 데몬을 생성하지 않는다. 여러 사용자가 이 방법으로 증상이 해소됨을 확인했고, 정상적인 CLI 작업 흐름을 해치지 않으면서 원치 않는 상주 프로세스를 막는 가장 확실한 조치로 꼽힌다.
실무적으로 짚어야 할 지점
단순한 편의 기능 논쟁을 넘어, 이 사안에는 신뢰 경계의 문제가 깔려 있다. 설치된 CLI의 정체성과 실제로 실행되는 데몬의 정체성이 어긋날 수 있다는 것이다. CLI가 자기 자신을 별도의 관리형 릴리스 디렉터리로 복사하고, 백그라운드 업데이터가 그 복사본을 교체할 수 있게 되면, 이후 요청을 처리하는 프로세스는 더 이상 사용자가 직접 설치하거나 호출한 그 산출물이라는 보장이 사라진다. 민감한 코드베이스나 자격증명에 접근하는 도구라면, '지금 내 명령을 수행하는 바이너리가 정확히 무엇인가'를 사용자가 확인할 수 없다는 점은 가볍게 넘길 사안이 아니다.
보안에 민감한 실무자라면 당장은 자동 업데이트 데몬을 끄고, 가능하면 코덱스 CLI를 격리된 환경(별도 호스트나 샌드박스)에서 돌리는 접근이 합리적이다. 다만 커뮤니티에서 나온 '악성코드' '봇넷' 같은 표현은 설치 체감에서 비롯된 격한 비유일 뿐, 실제로 그런 악의적 동작이 확인된 것은 아니라는 점은 분명히 구분해 둘 필요가 있다. 지금 확인된 사실은 두 가지다. 상주 자동 업데이트 데몬이 고지 없이 기본 활성화됐다는 것, 그리고 그 중단 절차에 업데이터가 남는 결함이 있다는 것. 설계 의도 자체는 데스크톱·원격 제어 시나리오를 위한 것으로 보이는 만큼, 핵심 요구는 결국 '기본값을 사용자가 선택하게 하라'로 수렴한다.