Projects / 実践記録

Codexを使い倒すなら、使用量だけでなくローカル環境も点検すべきって話

本ページはアフィリエイトプログラムを利用しています

最近、Codex Appをほぼ毎日見ている。

ブログの記事づくり、WordPressの下書き、公開後チェック、X投稿の依頼、開発中アプリの実装確認。
気づくと、かなりの時間をCodexの中で過ごしている。

そのぶん、最初に気になったのは使用量だった。
Codex Proの使用量リセットについては、以前にCodexのレート制限リセット機能？30日期限にご注意をにも書いた。

Codexを単発の相談ではなく、役割ごとの作業スレッドとして使う話は、Codexのthread toolで、AIチームの役割スレッドをつなぐにも書いている。
そこまで日常的に使うようになると、今度はローカル側の状態も気になってくる。

ただ、使い続けていると、もうひとつ気になる場所が出てきた。

ローカル環境です。

Codex AppやCodex CLIを毎日使うなら、見るべきなのは使用量メーターだけではない。
CLIのバージョン、codex doctor の結果、rollout履歴、SQLiteログDBのサイズ。

このあたりも、たまに見ておいた方がよさそうだと感じた。

今回は、2026年6月24日時点で自分のCodex環境を点検した記録です。
公式発表のまとめではなく、実際に運用していて確認したことを書いておく。

まずCodex CLIを0.142.0に更新した

今回、Codex CLIを 0.142.0 に更新した。

更新前は codex-cli 0.133.0。
更新後は codex-cli 0.142.0。

実行したのはこのあたりです。

codex --version
npm install -g @openai/codex@0.142.0
codex --version

OpenAIのCodex changelogを見ると、0.142.0では /usage や /plugins まわり、rollout token budget、multi-agent delegationなどに更新が入っている。
さらに、persistent-log churnを減らす変更も含まれている。

ここで大事なのは、changelogに書かれている機能が、自分の環境ですべて同じように見えるとは限らないこと。

CodexはApp、CLI、plugin、feature flag、アカウント状態で見え方が変わる。
だから、公式情報を見たうえで、最後は自分の環境で確認する。

まずはそこからだった。

codex doctorで、壊れているのか環境差なのかを見る

Codex CLIには codex doctor がある。

ローカルインストール、設定、認証、runtime、Git、terminal、app-server、thread inventoryなどをまとめて見てくれる診断コマンドです。

自分の環境では、2026年6月24日時点でこうなった。

17 ok · 1 idle · 2 notes · 0 warn · 0 fail ok

0 fail なので、少なくともdoctor上は大きく壊れている状態ではない。

ただ、最初からきれいに通ったわけではなかった。
一度、terminal checkが TERM=dumb でfailした。

これはCodex本体の故障というより、実行環境の環境変数の問題に見えた。
そこで、こう切り分けた。

codex doctor --summary
env TERM=xterm-256color codex doctor --summary

TERM=xterm-256color を指定するとdoctorが通った。

なので、いきなり再インストールしたり、設定を大きく変えたりする話ではなかった。
まず「Codex側の問題なのか」「実行しているterminal環境の問題なのか」を分ける。

doctorは、その切り分けに使いやすい。

rollout履歴は、全部まとめて消すものではなさそう

doctorで見ていて目についたのが、rollout履歴だった。

自分の環境では、active sessionsがだいたい9GB台。
filesは230件前後。

数字だけ見ると、まあまあ大きい。
でも、ここでいきなり削除するのは違う気がした。

Codexのrolloutやsessionは、ただのキャッシュではない。
resume、fork、thread inventory、過去の作業文脈に関係する可能性がある。

なので、自分の中ではこう分けた。

対象	基本判断
active sessions	基本は残す
archived sessions	不要なら削除候補
明らかに壊れた古いファイル	quarantineしてdoctor再確認
SQLiteログDB	中身を読まずサイズだけ見る

実際には、破損していた古いscan-error系のrolloutだけを隔離した。
active sessionsは残した。
archived sessionsは、不要なものだけ削除候補として扱った。

Codexを長く使うほど、履歴は増える。
でも、容量が大きいからといって、全部を掃除対象にすると後で困るかもしれない。

ここは「active」と「archived」を分けて考える方がよさそうです。

SQLiteログのissueは、煽らずサイズだけ見る

もうひとつ気になったのが、CodexのSQLiteログDBです。

GitHubの openai/codex には、SQLite feedback logsの書き込み量が大きいというissueがある。
報告者の環境では、かなり大きなSSD書き込み量になっていたという内容だった。

ただし、この数字を一般論として扱うのは危ない。
あくまで特定環境での報告です。

自分の環境では、2026年6月24日時点で以下のようなサイズだった。

logs_2.sqlite      約980MB
logs_2.sqlite-wal  約84MB
logs_2.sqlite-shm  約64KB

WALが極端に膨らんでいる状態ではなかった。
ただ、本体DBは約1GBある。

なので、自分の運用では「中身を見る」ではなく「サイズだけ見る」ことにした。

ls -lh ~/.codex/logs_2.sqlite*

SQLiteの中身には、会話や診断ログに近い情報が含まれる可能性がある。
だから、記事のためにDB本文を読む必要はない。

まずはサイズだけでいい。

急にWALが大きくなる。
短期間でDB本体が大きく増える。
そういう変化があった時だけ、追加で調べる。

GitHub issueにはログ挿入を止めるような回避策も出ていたけれど、自分はそこまではしない。
現時点では、0.142.0への更新とサイズ監視で十分と判断している。

自分用のCodexヘルスチェックを作った

毎回、手で見るのは面倒です。

なので、自分用に小さなCodexヘルスチェックスクリプトを作った。
手順を毎回プロンプトに書くより、再利用できる形に寄せるという意味では、AIに任せる仕事は、プロンプトではなくskillにした方がいいで書いた考え方にも近い。

やっていることはシンプル。

codex --version
codex doctor --summary
du -sh ~/.codex/sessions 2>/dev/null || true
du -sh ~/.codex/archived_sessions 2>/dev/null || true
ls -lh ~/.codex/logs_2.sqlite* 2>/dev/null || true

もう少しまとめるなら、こういう形で十分だと思う。

#!/usr/bin/env bash
set -euo pipefail

echo "# Codex Health Check"
echo
date
echo

echo "## CLI"
codex --version
echo

echo "## Doctor"
codex doctor --summary || true
echo

echo "## Local Sizes"
du -sh ~/.codex/sessions 2>/dev/null || true
du -sh ~/.codex/archived_sessions 2>/dev/null || true
ls -lh ~/.codex/logs_2.sqlite* 2>/dev/null || true

ポイントは、見に行く範囲を広げすぎないこと。

.env、token、cookie、認証ファイル、SQLiteの本文は読まない。
見るのはバージョン、doctor結果、サイズだけ。

自分の中では、このくらいがちょうどいい。

たとえば週1回、こうして残しておく。

./codex_health_check.sh > codex-health-check-$(date +%F).md

こうしておくと、「なんとなく重い気がする」ではなく、「前回よりDBが増えている」「rolloutが増えた」「doctorのnoteが変わった」と見えるようになる。

Codexを仕事道具として使うなら、このくらいの点検ログは残しておいてもよさそうです。

--oss、Ollama、LM Studioは今回はまだ入れない

Codex CLIのreferenceを見ると、--oss というオプションがある。

ローカルのopen source model providerを使うもので、Ollamaが動いていることを確認する説明になっている。

ここは正直、気になっている。

OllamaやLM Studioを組み合わせれば、軽い作業やローカル寄りの検証を別枠で回せる可能性はある。
ただ、自分の今の運用ではまだ入れていない。

理由は単純で、今はCodex App / CLI本体の運用を安定させる方が先だから。

使用量。
thread。
plugin。
doctor。
rollout。
ログDB。

ここを先に見えるようにしておく。

ローカルLLMは、機密性、オフライン作業、軽量タスクのコスト調整など、明確な目的が出てきたら試せばいい。
今回はそこまで広げない。

まとめ。Codexは使うだけでなく、点検する道具になってきた

Codexを単発のチャットとして使っている間は、ここまで気にしなくてもいいと思う。

でも、毎日開く。
複数のthreadを使う。
WordPressや開発作業や公開後チェックまで任せる。
そうなると、CodexはただのAIツールではなく、ローカルに状態を持つ作業環境になる。

作業環境なら、点検した方がいい。

まず見るのは、このくらいで十分です。

codex --version
codex doctor --summary
du -sh ~/.codex/sessions ~/.codex/archived_sessions 2>/dev/null || true
ls -lh ~/.codex/logs_2.sqlite* 2>/dev/null || true

削除や回避策から入らない。
まず、状態を見る。

Codexを毎日使うなら、使用量だけでなく、ローカル環境もたまに点検する。
しばらくは、この形で続けてみるつもりです。