開発チームにCodex CLIを使わせ始めたあと、ターミナルをすべて閉じても codex のプロセスが残っている、とPCの管理担当者が気づく。そうした場面（編集部の想定）で、何が動いているのか、止めてよいのか、どこで設定するのかを判断するための記事です。
OpenAIが公開しているCodexのリポジトリでは、2026年10月9日付のタグ rust-v0.162.1 の時点で、対話画面（TUI）の起動時に「共有のバックグラウンドサーバー」（app-serverのデーモン）を自動で立ち上げる機能が、既定で有効になっています。9月25日には、この既定を見直すよう求めるissueも立っています。10月15日に公開された0.163.0でも、この既定値は変わっていません。ソースとREADMEで確かめた範囲を、社用PCの運用の観点で整理します。
対話起動で、共有のバックグラウンドサーバーが立ち上がる
機能の定義（codex-rs/features/src/lib.rs）では、daemon_auto_start は次のように登録されています。
| 項目 | 値 |
|---|---|
| 説明 | Automatically start the shared local daemon for eligible interactive launches. |
| 段階（stage） | Stable |
| 既定値（default_enabled） | true |
起動処理（codex-rs/tui/src/startup_orchestration.rs）を読むと、--no-daemon を付けた起動や、リモートのワークスペースにつなぐ起動では自動起動しません。ほかにも、Amazon Bedrockのサインイン設定中、WSLでCodexの設定フォルダー（CODEX_HOME）がWindows側のドライブにある場合、Windowsで管理者として起動した場合は使わない分岐があります。
デーモンのREADMEは冒頭で、この仕組みを「experimental」とし、動作の取り決めは変わる可能性があると断っています。本記事の内容は10月9日のタグ（0.162.1）時点のもので、10月16日に0.163.0のタグでも、本文で取り上げた既定値・除外条件・READMEの記述（表と設定例の整形の違いを除く）が同じであることを確かめました。
一度動くと、ウィンドウを閉じても残り、更新を確かめ続ける
READMEとソースから、社用PCの管理で気にしておきたい動きを抜き出すと次のとおりです。
- 独立したプロセスとして動く。 pidファイルで管理される、ウィンドウから切り離されたプロセスとして起動します。状態は
CODEX_HOME/app-server-daemon/に置かれ、設定のsettings.json、プロセス記録のapp-server.pid、更新処理のapp-server-updater.pidなどがここに作られます - 自動更新が既定で有効。 設定の既定値は
auto_update_enabled: true、間隔は60分です。READMEには、対象のデーモンは起動の5分後、その後は1時間ごとに更新を確かめるとあります。更新処理が動くのは、安定版の最新チャンネルでインストールされ、更新に対応したバイナリの場合です。新しい版を取得すると、動いているサーバーを新しいバイナリで起動し直します - 再起動しても更新処理は残らない。 更新のループはOSの再起動をまたいで続かず、次にデーモンが起動したときに再び動き出します
- 環境変数は、最初に起動した時点のものを使い続ける。 READMEには「新しいターミナルを開いたり、そこで変数を消したりしても、動いているデーモンの環境は消えない。クライアントごとの環境の分離はない」と書かれています
- 遠隔操作は既定で無効。
remoteControlEnabledの既定はfalseで、codex remote-control startなどで明示的に有効にする仕組みです
9月25日に立てられたissue #48195（Codex CLI 0.157.0、npmでインストールしたWSL2のLinux環境の報告）は、この自動起動を「明示的に有効にする方式（既定で無効）」に変えるよう求めています。issueでは、codex app-server daemon stop でサーバーを止めても更新処理が動き続ける、という報告もあります。10月16日時点でもissueは未解決（open）で、OpenAIからの回答は確認できませんでした。この挙動は編集部では再現していません。
止める・抑えるための設定
リポジトリで確認できた設定とコマンドは次のとおりです。いずれも編集部は実行していません。
- その起動だけ使わない。
codex --no-daemonで起動します。CLIの説明は「すでに動いていても、共有のバックグラウンドサーバーを使わずに実行する」です - 自動起動を常に止める。
CODEX_HOME（既定は~/.codex）のconfig.tomlに次の1行を書きます。リポジトリのテストも同じ書き方で無効にしています
features.daemon_auto_start = false- 自動更新を止める・間隔を変える。
CODEX_HOME/app-server-daemon/settings.jsonのupdaterを編集します。READMEは、codex app-server daemon restartで有効・無効が反映されると説明しています
{
"remoteControlEnabled": false,
"shutdownGraceSeconds": 60,
"updater": { "autoUpdateEnabled": false, "updateIntervalMinutes": 120 }
}- 動いているサーバーを止める。
codex app-server daemon stopは、終了を求めたうえで、猶予（shutdownGraceSeconds、既定60秒、0〜300秒）を過ぎても残っていれば強制終了します - 状態を確かめる。
codex doctorはインストール・設定・認証・実行環境を診断するコマンドで、デーモンの状態は起動も停止もせずに報告するとソースに書かれています
なお、自動更新を止めても codex update や codex app-server daemon update を明示的に実行すれば更新されます。更新を止める場合は、セキュリティの修正をいつ取り込むかを別に決めておく必要があります。
社用PCで決めておくこと
ここからは編集部の提案です。
- 自動起動を認めるか。 常駐を避けたい端末では
config.tomlで無効にし、開発者のPCの初期設定に含める。認める場合も、端末の管理ツールでcodexのプロセスが残ることを把握しておく - 自動更新をどう扱うか。 版を固定して検証してから上げるのか、自動更新に任せるのかを決める。固定する場合は、更新の確認を誰がいつ行うかも決める
- 環境変数に秘密情報を置かない。 デーモンは最初に起動したときの環境を引き継ぐため、一時的に設定したAPIキーやプロキシの設定が残り続ける前提で考える
- 版が変わるたびに見直す。 READMEが「experimental」としているため、更新後に
features.daemon_auto_startの扱いや設定ファイルの場所が変わっていないかを確かめる
AIのコーディングエージェントにどこまでの権限を渡すかは、Docker Cloud Sandboxesで考えるエージェントの権限や開発者端末の拡張機能経由の侵害と端末管理でも扱っています。CLIの選び方そのものはClaude Code・Codex CLI・Copilot CLIの比較を参考にしてください。
確認した範囲
2026年10月14日に、GitHubの openai/codex リポジトリのタグ
rust-v0.162.1（2026年10月9日のコミット）を取得し、codex-rs/features/src/lib.rs、codex-rs/tui/src/startup_orchestration.rs・daemon_startup.rs・cli.rs、codex-rs/app-server-daemon/README.md・src/settings.rs・src/update_loop.rs、codex-rs/cli/src/main.rsを読みました。issue #48195 はページを取得して内容を確認しました（資料調査）。10月16日に、タグrust-v0.163.0（npmの@openai/codex0.163.0、10月15日公開）の同じファイルと比べ、issueの状態を確かめました。Codex CLIのインストールと実行、デーモンの起動・停止・更新の挙動、npm・Homebrewなどインストール方法による違いは確認していません。OpenAIの公式ドキュメントのCLIのページには、共有のバックグラウンドサーバーについての記述は見つかりませんでした。
開発端末でのAIツールの設定方針や、社内開発へのコーディングエージェントの組み込み方は、開発・AI・自動化のご相談からお問い合わせください。
