CodexレビューをサブPCで再現する条件と、Claude Codeステータスラインの仕組みを調べた
母艦PCで組み上げた開発環境が、いつの間にか「母艦でしか動かないもの」になっていないか。今日はその不安を2つ潰した。ひとつはCodexによるレビュー、もうひとつはターミナル下部に出しているステータスライン。どちらも「この便利機能、サブPCに引っ越したら再現できるんだっけ?」という疑問から始まって、Claude Codeに実環境を調べさせて答えを出した。
計画書や記事を書いたあと、Codex(GPT系)にセカンドオピニオンを取るのを習慣にしている。この「Codexレビュー」を別のサブPCのClaude Codeからも呼べるのか、そもそも今どういう設定で動いているのかが曖昧だったので、はっきりさせておきたかった。
引っ越しの当日に慌てるより、動いている今のうちに再現条件を言葉にしておきたい。そういう先送りしがちな棚卸しを、今日まとめて片付けることにした。
小ネタ1: CodexレビューをサブPCのClaude Codeで動かせるか
知りたかったこと
疑問は具体的だった。サブPCのClaude Codeに「これレビューして」と頼んだとき、Codexが動く条件は何か。頭の中では「CLIがダウンロードされていて、レビュー用のスキルかプラグイン、名前は忘れたけどそれが入っていれば動くんじゃないか」くらいの解像度しかなかった。プラグインなのかスキルなのか、認証はどう引き継ぐのか、そのあたりが宙ぶらりんだった。
「なんとなくこうだった気がする」で別PCに移ると、いざ本番でレビューが空振りする。だから記憶ではなく、母艦PCの実物の構成をClaude Codeに調べさせて、再現手順まで固めさせることにした。
実環境で調べさせたこと
Claude Codeに母艦PCの現状構成を確認させた。見てほしかったのは3点。
- Codexレビューの実体は何を叩いているのか(コマンドか、スキルか、プラグインか)
- 認証はどの方式か(トークンファイルの共有か、各PCでのログインか)
- プラグインやスキルは必須の前提なのか
分かったこと
結論はシンプルだった。Codex CLIが入っていて codex login が済んでいれば、サブPCのClaude Codeでもそのままレビューを頼める。 レビュー本体がやっているのは、要するにこれ1行を叩くことだった。
codex exec -m gpt-5.5 "このプランをレビューして。致命的な点だけ指摘して: {対象ファイルのパス}"
つまりレビューの正体は「Claude CodeがCodex CLIをコマンドとして呼んでいる」だけで、プラグインもスキルも必須ではない。手元のスキルは呼び出しを楽にするラッパーであって、なくてもコマンドを直接叩けば同じことができる。これが分かって、サブPCへの引っ越しがぐっと軽くなった。
引っかかったのは認証だった。母艦の auth.json をサブPCにコピーして済ませたくなるが、そこは各PCで codex login を通すのが正解。トークンファイルの横流しではなく、PCごとにログインし直す前提で運用する。ここを勘違いすると、サブPCで初回レビューを叩いた瞬間に認証エラーで止まる。
考えてみれば、認証情報はPCという境界の内側で完結させておくほうが後腐れがない。トークンファイルを持ち歩くと、どのPCにいつのトークンを撒いたか分からなくなるし、片方を処分するときに消し忘れる。各PCで codex login を踏む一手間を、引っ越しの初期化コストとして受け入れるのが結局いちばん楽だと腹落ちした。
サブPCでの再現に必要なものを、最小構成で並べるとこうなる。
- Codex CLI をインストールする
- そのPCで
codex loginを通す(auth.jsonのコピーで済ませない) - あとはClaude Codeに
codex exec -m gpt-5.5 "..."を叩かせるだけ(プラグイン・スキルは任意)
おまけ: 「クソリプ回避」の一文はどこに入れていたか
調べているうちに、もうひとつ思い出した。Codexは放っておくと瑣末な指摘(本質的でない、いわゆるクソリプ)を返してくるので、「瑣末な点は指摘するな、致命的な点だけ挙げろ」という一文を必ず添えている。この設定、フックか何かで自動注入していた気がしていたが、記憶を辿ると違った。
正体は、レビュー依頼のプロンプト文そのものに直書きしているだけだった。フックのような仕込みではなく、codex exec に渡す指示文の中に毎回その一文を入れている。だからサブPCで再現するときも、特別な設定ファイルを移す必要はなく、レビュー依頼の文面にこの一言を足せばそのまま効く。仕組みが単純なぶん、移設で壊れる余地がないのがありがたい。
小ネタ2: 「今どのリポジトリにいるか」を出すステータスラインの設定
知りたかったこと
ターミナルの下に、今いるリポジトリ名などを出すステータスラインを常用している。ただ、これをどう設定して出していたのか自分でも思い出せなくなっていた。スクリーンショットをClaude Codeに見せて、「この表示ってどういう設定で出しているんだっけ」と素朴に聞くところから始めた。
調べさせたこと
Claude Codeに設定の入口を辿らせた。分かったのは、これがClaude Codeの statusLine 設定で、自作のPythonスクリプトを動かしている2段構成だということ。
- 入口:
~/.claude/settings.jsonのstatusLine項目。ここで表示に使うスクリプトを指定している - 本体: 指定した自作Pythonスクリプトが、リポジトリ名などを組み立ててステータスラインの文字列を返す
「設定ファイルが表示スクリプトを呼び、スクリプトが中身を描く」という素直な2段構えで、Claude Code標準のstatusLineの仕組みにそのまま乗っているだけだった。凝ったことは何もしていない。
分かったこと
もうひとつ確かめたかったのが、このステータスラインのPythonスクリプト一式をどこで管理しているか。母艦にしかないローカルファイルだと、サブPCで再現できない。
調べさせたら、~/.claude ディレクトリ自体がまるごと git リポジトリになっていて、GitHub上のdotfilesリポジトリで追跡していた。ステータスラインのPythonスクリプトもそこにコミット済みで、未コミットの差分はなし。旧版らしきシェルスクリプト版も同じリポジトリに残っていた。
これで安心した。設定もスクリプトも ~/.claude 配下にあってgit管理されているので、サブPCでdotfilesをクローンすれば、ステータスラインの表示までそっくり引き継げる。バラバラのローカルファイルではなく、リポジトリ1つに畳んであったのが今日いちばんの収穫だった。
ここでも構図はCodexレビューと同じだった。表示という「見た目の便利機能」でも、実体をたどれば設定ファイルとスクリプトのペアに過ぎず、それがgitに乗っていれば再現は clone 一発。逆に言えば、gitに乗っていない自作機能こそ、サブPCで真っ先に消える。今日のうちに「乗っている/乗っていない」を目視で確かめておけたのが効いた。
今日の学び
2つとも「便利機能がPC固有になっていないか」という同じ不安から始まって、同じ結論に着地した。
- Codexレビュー: 実体は
codex execを叩くだけ。プラグインもスキルもなくていい。移設で唯一気をつけるのは、認証を各PCでcodex loginし直すこと - ステータスライン: Claude Code標準のstatusLineに自作Pythonスクリプトを噛ませているだけ。設定もスクリプトも
~/.claudeのdotfilesリポジトリに入っているので、クローンすれば再現できる - 「なんとなく動いている環境」を、記憶ではなく実物で棚卸しさせておくと、サブPCへの引っ越しが怖くなくなる。凝った仕組みほど再現条件を1回言語化しておく価値がある
次にサブPCへ移設するときに、今日の棚卸しを1枚のチェックリストに畳んでおく。
- dotfiles(
~/.claude)をクローンする(settings.jsonとステータスラインのスクリプトが一緒に付いてくる) - Codex CLI をインストールする
- そのPCで
codex loginを通す(auth.jsonはコピーしない) - ステータスラインが表示されるか、ターミナルを開いて目視する
- 適当なファイルで
codex exec -m gpt-5.5 "..."を一度叩き、レビューが返ってくるか確かめる
ここまで確認できれば、母艦とサブPCの体験差はほぼ消える。便利機能を作った日ではなく、それを別PCで再現できると確かめた日のほうが、あとから効いてくる気がした。