OpenAI の Codex CLI を使っていた開発者が、あるバージョンから「いつの間にか裏で常駐プロセスが動き出す」挙動に強く異議を唱えました。問題にされたのは、単に新機能が増えたという話ではなく、CLI らしさそのものを壊しかねない設計です。しかも議論は、起動のたびに daemon が立つこと、勝手に更新されること、環境変数まで引き継いでしまうことへと広がっています。GitHub の issue には賛同や不満が次々集まり、かなり実害のある変更として受け止められている様子が見えます。
issue を立てたユーザーが使っていたのは Codex CLI 0.157.0 で、npm install -g @openai/codex によって入れた Linux（WSL2）環境だと書かれています。訴えの中心は、CLI の対話セッションを開くだけで codex app-server --managed-daemon という persistent なバックグラウンド daemon が立ち上がることでした。この daemon は TTY を持たない独立セッションで走り続け、Codex のウィンドウを閉じても残り、codex app-server daemon stop を実行するか再起動するまで消えないと説明されています。
さらに、この daemon は CLI が入っていた場所とは別に、~/.codex/packages/app-server-daemon/releases/<version>/ にプラットフォーム一式をコピーしてそこで動きます。コピーされる中身は codex、codex-code-mode-host、bundled の bwrap、zsh、rg を含み、サイズはおよそ 374 MB と具体的に書かれています。つまり、パッケージマネージャーで入れた CLI と、実際に裏で動く backend の版が分離するわけです。ユーザーはこれを「自分が入れたバイナリではなく、別の managed copy が勝手に走る」状態だと見ています。
問題は起動だけではありません。daemon には pid-update-loop という更新用プロセスも付き、起動 5 分後から、その後は毎時アップデートを確認します。新しい release を落として backend を再起動するため、作業中の turn が強制終了される可能性もあるとしています。本人は、すでに別 issue で「自動更新が 60 秒の猶予後に active turns を force-kill する」と報告されている点も挙げました。
加えて、daemon は最初に起動したセッションの環境を固定してしまうようです。投稿者は invocations ごとに HTTPS_PROXY を切り替える wrapper を使っているのに、daemon は最初の proxy 設定を保持し続け、後から開いたセッションの設定を反映しないと述べています。--remote モードでは hooks が daemon の cwd を受け取ってしまう件、client terminal を識別できない件も、同じ根っこにある不具合だろうと関連 issue が並べられました。
そのうえで投稿者は、CLI なら backend は「ウィンドウと一緒に生まれて一緒に死ぬ」ほうが自然で、勝手に更新しないほうが驚きが少ないと主張します。共有 daemon や self-updating の仕組みは Remote Control やデスクトップアプリには向いているかもしれないが、少なくとも CLI の標準動作にするべきではない、という立場です。もし default のまま続けるなら、最後の client が切れたら daemon も終了すること、npm や brew や pacman のようなパッケージマネージャーで入れた場合はコピーせずインストール済みの binary を使うことを求めています。
投稿ではさらに、codex app-server daemon stop が backend 本体は止めても pid-update-loop を残してしまったという副作用も報告されました。回避策としては、codex features disable daemon_auto_start を実行し、daemon を止め、pkill -f 'app-server daemon pid-update-loop' で updater を殺し、~/.codex/packages/app-server-daemon を削除する流れが記されています。この flag を切ると、新しい TUI session は daemon を起動しなくなるとも書かれています。
コメント欄では、他の利用者も「未知の server や process が小さな version bump で突然増えるのは困る」「CLI が使いものにならない」「Windows でも再現する」と反応し、設定で daemon_auto_start = false にすると直ると報告する声もありました。後には「この issue に対応する commit が入った」と見られる記録も残っており、少なくとも議論がコード変更につながったことはうかがえます。
この話でいちばん引っかかるのは、機能の善し悪しよりも、どこまでをユーザーが予想できるかだと思います。CLI は本来、開いた端末の中で完結する道具です。ところが今回の Codex は、ユーザーが見えていない場所で別の実行体を作り、更新まで自分で回し始める。便利さは確かにありますが、初回起動時に説明がなかったなら「それは違うだろう」と感じる人が出るのは自然です。少なくとも、opt-in にして「使いたい人だけ使う」に寄せるのは筋が通っています。
しかも、今回の懸念は単なる気分の問題ではありません。daemon が最初のセッションの環境を引きずるなら、HTTPS_PROXY のような設定は壊れますし、cwd や terminal の扱いがずれるなら hook も誤作動します。つまり、見えない常駐化は、UI の好みではなく実務上のバグを生みます。CLI を「一回の実行ごとに環境が決まるもの」として使っている人ほど、ここで被害を受けやすいはずです。
もうひとつ重要なのは、インストール経路と実行経路が分かれてしまっている点です。npm で入れたなら npm の管理下、brew で入れたなら brew の管理下で動いてほしい、という感覚はかなり普通です。ところが issue の報告では、Codex は自分で ~/.codex/packages/... に複製を作り、その後はそちらを更新し続けます。ユーザーから見れば、パッケージマネージャーが管理しているはずのソフトが、別のレイヤーにもう一体いるようなものです。
ここで怖いのは、更新の責任所在が曖昧になることです。CLI の版が変わっていないのに backend だけが更新されるなら、障害が起きたときに「今どの版が動いているのか」を追うのが難しくなります。コメントにあった「provenance boundary」という指摘は、かなり本質を突いていると思います。利用者が明示的に入れた artifact と、バックグラウンドで勝手に入れ替わる artifact が違うなら、少なくともそれを確認できる仕組みが必要です。
この issue が面白いのは、単なる「嫌だ」という感情論で終わっていないことです。投稿者は、サーバを共有化したり自己更新させたりする発想自体を全面否定しているわけではありません。Remote Control や desktop app なら、そのほうが合理的な場面は確かにあります。ただし、CLI の既定動作に持ち込むと、更新失敗、設定の持ち越し、予期しない再起動、終了しない updater まで一気に問題が増える。安全性や利便性を上げるはずの仕組みが、別の面では信頼を削るわけです。
実際、コメントには「マルウェアみたいだ」という強い言葉まで出ています。言い過ぎだと思う一方で、感情の温度は理解できます。ユーザーが把握していないプロセスが常駐し、外に通信し、裏で更新される。技術的には正当でも、体験としては不気味です。LLM 系のツールは権限も影響範囲も大きいので、こうした違和感はなおさら軽く扱えません。少なくとも「便利だからデフォルト」で押し切る段階ではない、というのがこの issue の重みだと思います。
Codex だけの特殊事情として片づけるのは少し危険です。AI を使う開発ツールは、単体アプリというより「端末・ネットワーク・認証・hook・リモート実行」を束ねる存在になりつつあります。そのぶん、裏で何が動いているかが見えないと、ユーザーはすぐ不安になります。特に enterprise や社内環境では、プロキシや監査、端末の識別が崩れるだけで採用をためらう理由になります。
だから本当は、daemon を入れるかどうか以上に、どう見せるかが大事です。自動起動するなら初回に必ず確認する、更新されるなら今どの generation が動いているかを明示する、環境を引き継ぐならその境界をログに出す。そうした透明性があって初めて、便利な常駐化は受け入れられるはずです。今回の issue は、その線を越えた瞬間にコミュニティが強く反応する、という見本になったと感じます。
