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 のラベルが付いています。

デーモンは報告者が驚くべきデフォルトと考える4つのことを行う

イシューによると、対話型の codex セッションを開くだけで以下のすべてが発生します。

1. 永続的なバックグラウンドデーモンを起動する（codex app-server --managed-daemon）。このプロセスは TTY なしの独自セッションで実行され、すべての Codex ウィンドウが閉じられた後も PID 1 にリペアレントされて実行し続け、codex app-server daemon stop または再起動まで停止しません。
2. プラットフォームパッケージ全体をコピーする — 約374 MB で、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. 起動したセッションの環境を固定する。報告者は Codex を起動する際に呼び出しごとに HTTPS_PROXY を設定するラッパーを使用しています。デーモンは最初のセッションのプロキシ変数を保持するため、後続のセッションがどのような環境で起動されても、デーモンの外部接続はそのプロキシを経由します。

報告者は環境固定の挙動を イシュー #42457（--remote モードのフックがセッションの cwd ではなくデーモンの cwd を受け取る）および イシュー #37537（app-server デーモンが生成したフックがクライアント端末を識別できない）と関連付け、同じ根本原因のように見えると述べています。

報告者の表明した期待: CLI のバックエンドはウィンドウとともに生き、死ぬべき

このイシューは、コマンドラインツールの最小驚きのデフォルトを中心に要求を組み立てています。

CLI にとって最も驚きの少ないデフォルトは、バックエンドがウィンドウとともに生き、死に、私がインストールしたバイナリを実行し、バックグラウンドで自己更新しないことです。共有・自己更新型デーモンは Remote Control / デスクトップアプリには理にかなっているので、そこや、ユーザーが明示的に codex app-server daemon start / bootstrap を実行した場合に有効にするのは問題ないでしょう。

デフォルトが維持される場合、報告者は2つのフォールバックを求めています: 最後のクライアントが切断されたら自動起動されたデーモンを終了すること、そして 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 はまた、2つの改善案を提案しました: デーモンの起動が昇格（elevation）によってブロックされた場合に --no-daemon を要求するのではなく自動的にローカルモードにフォールバックすること、そしてデーモンの自動起動をデフォルトではなくオプトインにすることです。イシュー作成者は両方とも有効だと返信しました。

ユーザー felipeelopes は、Windows でこのバグにより Codex CLI が使用不能になっていると書きました。メンテナの立場で応答していると思われるユーザー megahall は、次のように書きました:

報告ありがとうございます、私自身も遭遇しました... 小さなバージョン番号の変更で、事前の警告なしに突然謎のサーバーやプロセスを作成するようなことは避けるべきです...

ユーザー kr8vka0z は、修正されるまで CLI は使用不能だと書きました。ユーザー skhaz は「+1 for disabling this.」と追加しました。ユーザー laurynas-karvelis はより率直でした:「基本的に - マルウェアの特徴だ。正直、これが偶然だとは思えない。」

来歴の議論: インストールされた CLI のアイデンティティはデーモン実行のアイデンティティではない

ユーザー aetherxeg-source のコメントは、この問題を来歴の境界問題として捉え、インストールされた CLI のアイデンティティ != デーモン実行のアイデンティティ と述べました。その議論は、CLI が自分自身を管理されたリリースディレクトリにコピーし、バックグラウンドのアップデータがそのコピーを置き換えることができるようになると、後続のターンを処理するプロセスは、ユーザーが明示的にインストールまたは起動した成果物であるとは限らなくなるというものです。

このコメントは、デーモンが各クライアント接続に対して、少なくとも client_cli_version + daemon_binary_digest + daemon_generation + updater_state + inherited_environment_generation を含む小さな実行レシートを公開し、クライアントが4つの状態を区別できるようにすることを提案しています: 同じインストール済み成果物と同じデーモン世代; 同じ 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 は、デーモン自体ではなく環境の挙動を特に取り上げました:

このデフォルト変更の最もユーザー敵対的な側面は、「コマンドは起動されたシェル環境で実行される」という慣習/期待を静かに壊すことだと思います。例えば、有効な環境を確認するセッション起動フックは、app server の環境で実行されるため失敗します。また、モデルコンテキストサイズなど、ほぼすべての -c 引数を渡すと、静かにデーモンの使用をやめます。

プラットフォーム固有の破損: Windows コンソールウィンドウと昇格

ユーザー ilitirit は、Windows ではツールが「コマンドを実行するたびに新しいコンソールウィンドウも起動する」と報告し、--no-daemon で無効化するようアドバイスし、CLI は「2週間前までは完全に使用可能だった」と付け加えました。GitHub イシューでの tagorr と felipeelopes による Windows での確認は、同じプラットフォームが不均衡に影響を受けていることを示しており、tagorr は特に、デーモンの起動が昇格によってブロックされた場合にローカルモードへの自動フォールバックを求めています。

Codex と AI ハーネスの品質に関するより広範な不満

複数のコメンターが、デーモンだけではなく AI コーディングツールの全体的な状態を批判するためにこのスレッドを利用しました。

ユーザー Alifatisk は、Codex VS Code 拡張機能を「どれだけ脆いか信じられない」と表現し、約1週間完全に壊れてから部分的に修正され、複数のイシューが同じ問題を追跡しており、コミュニティが自分たちで拡張機能にパッチを当て始めていると述べました。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 に依存し、システムプロンプトの1行で必要に応じて CLI ツールを追加していると説明しました。ユーザー sva_ は、Pi Coding Agent を「はるかに軽量で、私の経験ではプロプライエタリなハーネスのどれよりもはるかに優れている」と推奨しました。ユーザー silverbluep は、Codex が「状態と設定データを混在させる」ため、nix-darwin 環境での宣言的管理が妨げられ、Codex を放棄し、現在は opencode を通じてのみ Codex を使用していると述べました。ユーザー pkulak は緩和要因を指摘しました:「OpenAI は少なくとも、好きなハーネスを使うことを許可しています。粗末なファーストパーティ製のものは悪いですが、逃げ道があれば下限が設定されます。」

イシューが求めていること、一言で

Codex CLI の daemon_auto_start をデフォルトで false にするか、有効化する前に一度プロンプトを表示すること。デフォルトが維持される場合は、最後のクライアントが切断されたらデーモンを終了し、CLI がパッケージマネージャーでインストールされた場合はコピーや自己更新を停止すること。イシューの最終アクティビティが2026年10月12日時点で、このイシューはアサインなし、マイルストーンなし、リンクされたプルリクエストなしのままオープンです。