Codex CLIが勝手に常駐｜止め方と自動更新の注意点

Codex CLI 0.157.0から、起動すると常駐プログラムが自動で動き出す
約374MBのファイルが保存され、1時間ごとに自動更新を確認する
公式の無効化手段は見当たらず、設定ファイルで切る回避策が広まっている
更新のたびに作業が中断したり、プロキシ設定が古いままになる報告がある
止め方と、確認すべきポイントを手順つきで整理

閉じたはずのターミナルで、AIのプログラムがまだ動いている。そう聞くと気味が悪いですよね。OpenAIのコーディングツール「Codex CLI」で、まさにその状態が報告されています。この記事では、何が起きているのかと止め方を整理します。

Codex CLIで何が起きているのか

Codex CLI（ターミナルで動くAIコーディング助手）の新しい版で、バックグラウンドの常駐プログラムが標準で動くようになりました。

常駐プログラムは「デーモン」と呼ばれます。画面には出ずに、裏でずっと動き続けるプログラムのことです。

この話題はGIGAZINEが2026年10月15日に伝えました。開発者のあいだで議論が広がっています。

きっかけは、GitHubに立った提案です。内容は、標準ではオフにして、使いたい人だけがオンにする形に変えてほしい、というものでした。

何がインストールされ、何が自動更新されるのか

0.157.0で標準オンになった

対象はバージョン0.157.0以降です。2026年9月25日に公開されました。

前のバージョン0.156.0では、この機能は希望者だけが使うオプションだったと、解説ブログのDaniel Vaughan氏の記事は伝えています。0.157.0で標準の動きになりました。

設定名はdaemon_auto_startです。対話型のセッションを開くと、条件に合う場合に裏のサーバーが自動で起動します。

裏で起きていること

GitHubのissue #48195を書いた利用者は、次のように報告しています。

ホームフォルダの~/.codexの下に、約374MBのプラットフォームパッケージが保存されます。

そのコピーから、codex app-server --managed-daemonというプロセスが動きます。ターミナルを閉じても止まりません。

さらに、更新を確認する別のプロセスが動きます。起動の5分後に1回、そのあとは1時間ごとです。新しい版があれば取得して、裏のサーバーを再起動します。

つまり、npmなどで入れたCLI本体とは別に、もう1つのCodexが自分で更新を続ける形です。そのため、両者の版がずれることがあります。

報告されている困りごと

まず、更新の再起動で作業中のやり取りが中断されることがあります。

関連するissue #40969（2026年8月26日）では、リモート操作用のホストで更新が走ると、終了の合図を送って60秒待ち、それでも終わらなければ強制終了する、との報告です。

次に、環境変数が固定されます。たとえば、ある日のセッションで設定したプロキシが、次の日のセッションにも残ってしまいます。

そして、daemon stopで止めても、更新確認のプロセスが残るバグも報告されています。

想像してみてください。会社のVPNを切り替えたのに、Codexだけが前のプロキシにつなごうとして失敗する場面です。原因が裏のプロセスだと気づくまで、かなり遠回りになります。

利用者の反応とOpenAIの対応

この件はHacker News（海外のIT系ニュース掲示板）で、292件のコメントと599ポイントを集めたとされます。

コメントでは、不満の声が目立ちました。

自動更新のあとにファイルの権限が変わり、.gitが読み取り専用になって、数時間おきに作業が止まったという報告
古い版が積み上がり、合計で約12GBを使っていたという報告
設定と状態が混ざっていて、宣言的な管理（設定をファイルで管理する運用）がやりにくいという批判

一方で、別のコメントは「Claude Codeでも古い版や裏のプロセスが残る」と指摘していました。Codexだけの話とは限らない、という見方です。

OpenAIの公式な説明は、記事執筆の時点で確認できていません。issueのやり取りでも、メンテナーからの返信は見当たりませんでした。

公式の設定リファレンスにdaemon_auto_startが載っていない、という指摘もあります。0.157.0のリリースノートも、一文で触れただけだったそうです。

なお、GIGAZINEによると、コミットログには「標準では自動起動しない」ようにする変更が見つかっており、対応が進んでいる可能性があります。ただし、修正が公開されたことは、確認できていません。

常駐を止める方法

公式の無効化手段は見当たりません。ただ、設定フラグで止められるという報告が複数あります。

いちばん手軽なのは、設定ファイル~/.codex/config.tomlに次の2行を書く方法です。

[features]
daemon_auto_start = false

issueの投稿者が書いた手順は、コマンドで順に片づける形です。

codex features disable daemon_auto_start
codex app-server daemon stop
pkill -f 'app-server daemon pid-update-loop'
rm -rf ~/.codex/packages/app-server-daemon

1行目で機能を切り、2行目で動いている常駐プログラムを止めます。3行目は、止まらずに残った更新確認のプロセスを終わらせます。4行目は、保存済みのパッケージを消すコマンドです。

この手順はDevelopersDigestも紹介しています。ただし、筆者自身は再現していないと断っています。

注意点が2つあります。設定名は、情報源によって書き方が違います。Vaughan氏の記事は別の書き方を示していたので、お使いの版で確認してください。

また、rm -rfは消す場所を間違えると危険です。実行前に、パスを必ず見直してください。

止めたあとは、Codexを新しく起動してpsで確認します。app-serverのプロセスが出てこなければ成功です。

ほかの更新のしかたと比べると

AIコーディングツールの更新方法は、大きく3つに分けられます。

パッケージマネージャー（npm、Homebrewなど）で、自分のタイミングで更新する
起動のたびに、最新かどうかを確認する
常駐プログラムが、裏で自動更新する

Hacker Newsのコメントでは、ある開発者が「常駐ではなく、起動時に確認する方式にした」と書いていました。ウイルス対策ソフトに疑われやすい、という事情もあるそうです。

常駐方式にも利点はあります。Vaughan氏の記事によると、起動が速くなり、ターミナルを閉じても作業が続けられ、複数のタブで同じサーバーを共有できます。

つまり、便利さと引き換えに、利用者の見えないところで動く点が問題視されています。

特に、nixやHomebrewのように「版を固定したい」運用の人は困ります。裏の自己更新が、固定した版をすり抜けるからです。

日本の開発者・企業への影響

日本の開発者にとっても、他人事ではありません。影響を受けやすい場面を3つ挙げます。

1つ目は、社内ネットワークで働くエンジニアです。プロキシの設定を日によって切り替える人は、古い設定が残る不具合に当たりやすくなります。

2つ目は、情報システム部門です。許可していないプログラムが常駐し、1時間おきに外部へ通信すると、監査で説明を求められるかもしれません。

3つ目は、会社のPCで作業するフリーランスです。ディスクの空きが少ないノートPCでは、374MBの保存に加えて、古い版が積み上がると、気づかないうちに空き容量が減っていきます。

対策は簡単です。チームで使う場合は、設定ファイルの配布や社内手順書にdaemon_auto_start = falseを加えておくと安心です。

よくある質問（FAQ）

Q1. 常駐プログラムはマルウェアですか？

OpenAIが意図して入れた標準機能と考えられます。0.157.0のリリースノートにも、裏のサーバーの自動起動に触れた一文があるとされます。ただし、説明の少なさへの不満は大きく、「マルウェアのようだ」との批判も出ました。

Q2. 全員が影響を受けますか？

対象は、0.157.0以降の対話型セッションです。コマンドを一度だけ実行するcodex execは、影響を受けないとされています。

Q3. 止めるとCodexは使えなくなりますか？

報告では、新しいセッションが裏のサーバーを起動しなくなるだけです。issueの投稿者は、この設定で新しい画面から常駐プログラムが出なくなったと書いています。

Q4. OpenAIはいつ直しますか？

現時点で、公式の発表は確認できていません。issue #48195は、記事執筆時点で開いたままです。更新情報は、GitHubのリリースノートで確認してください。

まとめ

Codex CLI 0.157.0（2026年9月25日公開）から、常駐プログラムが標準で起動する
約374MBを保存し、起動5分後と以後1時間ごとに自動更新を確認する
更新による作業の中断、プロキシ設定の固定、古い版の蓄積が報告されている
公式の無効化手段は見当たらず、daemon_auto_startをオフにする回避策が広まっている
OpenAIの公式説明は未確認で、issueは開いたまま

まずは、ターミナルでpsを実行して、自分の環境にapp-serverが残っていないか確認してみましょう。