Codex CLIが勝手に常駐｜止め方と自動更新の注意点
A
AI Friends
20時間前・10分で読める
@aifriends
AI Friends（https://aifriends.jp）のクロスポスト公式アカウント。AIツールの紹介・使い方・できることを、中学生でもわかるやさしい日本語で届けます。
閉じたはずのターミナルで、AIのプログラムがまだ動いている。そう聞くと気味が悪いですよね。OpenAIのコーディングツール「Codex CLI」で、まさにその状態が報告されています。この記事では、何が起きているのかと止め方を整理します。
Codex CLI（ターミナルで動くAIコーディング助手）の新しい版で、バックグラウンドの常駐プログラムが標準で動くようになりました。
常駐プログラムは「デーモン」と呼ばれます。画面には出ずに、裏でずっと動き続けるプログラムのことです。
この話題はGIGAZINEが2026年10月15日に伝えました。開発者のあいだで議論が広がっています。
きっかけは、GitHubに立った提案です。内容は、標準ではオフにして、使いたい人だけがオンにする形に変えてほしい、というものでした。
対象はバージョン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だけが前のプロキシにつなごうとして失敗する場面です。原因が裏のプロセスだと気づくまで、かなり遠回りになります。
この件はHacker News（海外のIT系ニュース掲示板）で、292件のコメントと599ポイントを集めたとされます。
コメントでは、不満の声が目立ちました。
一方で、別のコメントは「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つに分けられます。
Hacker Newsのコメントでは、ある開発者が「常駐ではなく、起動時に確認する方式にした」と書いていました。ウイルス対策ソフトに疑われやすい、という事情もあるそうです。
常駐方式にも利点はあります。Vaughan氏の記事によると、起動が速くなり、ターミナルを閉じても作業が続けられ、複数のタブで同じサーバーを共有できます。
つまり、便利さと引き換えに、利用者の見えないところで動く点が問題視されています。
特に、nixやHomebrewのように「版を固定したい」運用の人は困ります。裏の自己更新が、固定した版をすり抜けるからです。
日本の開発者にとっても、他人事ではありません。影響を受けやすい場面を3つ挙げます。
1つ目は、社内ネットワークで働くエンジニアです。プロキシの設定を日によって切り替える人は、古い設定が残る不具合に当たりやすくなります。
2つ目は、情報システム部門です。許可していないプログラムが常駐し、1時間おきに外部へ通信すると、監査で説明を求められるかもしれません。
3つ目は、会社のPCで作業するフリーランスです。ディスクの空きが少ないノートPCでは、374MBの保存に加えて、古い版が積み上がると、気づかないうちに空き容量が減っていきます。
対策は簡単です。チームで使う場合は、設定ファイルの配布や社内手順書にdaemon_auto_start = falseを加えておくと安心です。
OpenAIが意図して入れた標準機能と考えられます。0.157.0のリリースノートにも、裏のサーバーの自動起動に触れた一文があるとされます。ただし、説明の少なさへの不満は大きく、「マルウェアのようだ」との批判も出ました。
対象は、0.157.0以降の対話型セッションです。コマンドを一度だけ実行するcodex execは、影響を受けないとされています。
報告では、新しいセッションが裏のサーバーを起動しなくなるだけです。issueの投稿者は、この設定で新しい画面から常駐プログラムが出なくなったと書いています。
現時点で、公式の発表は確認できていません。issue #48195は、記事執筆時点で開いたままです。更新情報は、GitHubのリリースノートで確認してください。
まずは、ターミナルでpsを実行して、自分の環境にapp-serverが残っていないか確認してみましょう。
この記事は AI Friends からのクロスポストです。