Codex を GPT-6 Sol へ上げ、ステータスラインにエフォートを出し、yt-dlp の JS ランタイム警告を deno で直した
Codex を GPT-6 Sol へ上げ、ステータスラインにエフォートを出し、yt-dlp の JS ランタイム警告を deno で直した
9月23日は、AI まわりの道具を三つ手入れした。 朝は Codex のモデル更新、昼すぎは Claude Code のステータスラインと、自作の Chrome 拡張の動画ダウンロードである。 三つめは、直したあとにダウンロードボタンが画面から消えた。
Codex を GPT-6 Sol へ上げる
Codex のモデル一覧に、GPT-6 Astra のほかに GPT-6 Sol が出てきていた。 これまで使っていたのは 5.6 の Sol なので、GPT-6 の Sol へ上げたい。 気になっていたのは、コミット前にレビューするフックのモデル指定である。 Astra になっているのか、5.6 のまま残っているのか、自分でも把握できていなかった。 ついでに、レビューで Astra を使っている箇所はそれでいいのかも、Claude Code に聞いた。
Claude Code は、gpt-6-sol がモデル一覧にあるのを見てから、実際に呼べるかを短く確かめた。
そのうえで、コミット前レビューのフック（Codex がステージ差分を読み、問題があればコミットを止める仕組み）を gpt-5.6-sol から gpt-6-sol に切り替えてもらった。
5.6 のまま残っていたのは、やはりフックだけだった。
Astra を使っているドキュメントレビューは、そのままで問題ないという答えだった。
変更は ~/.claude の中の4ファイルである。
「コミットしといて」と頼むと、5c48270 としてコミットされた。
このコミットが、そのまま新しいモデルの試運転になった。
コミットのとき、フックが gpt-6-sol（effort=high）で差分をレビューし、critical と high の指摘は出なかった。
新しいモデルでもフックが動くことを、試験を別に組まなくても確かめられた。
コミットに入れたのは変更した4ファイルだけで、関係のない未追跡の state/ は入っていない。
Opus 5.5 と Sonnet のどちらを使うか
同じセッションで、スクリーンショットを1枚貼って相談した。 貼った画像を見ると、Sonnet より明らかに良さそうに思えた。 それなら、いまは Sonnet ではなく Opus を使うべきなのか、という質問である。 音声入力だったので、モデル名は「Sonnet 3.5」「Opus 3.5」のようにずれて入っていた。
Claude Code はこれを「Opus 5.5 を使うべきか、Sonnet や Fable 5.1 のままでいいか」という質問に読み替えて答えた。 Opus 5.5 を使うのがいいと思う、という答えだった。 しかも、このセッションはすでに Opus 5.5 で動いていた。
「5.5。」とだけ返すと、グローバルの CLAUDE.md にある現行モデルの記述を Opus 5.5 に直し、33c99d7 としてコミットしてもらえた。
書き換えた一文は次のとおり。
現行モデルは Opus 5.5（2026-09-23 更新。それ以前は Opus 5）
ステータスラインにエフォートのレベルを出す
昼すぎ、Claude Code のステータスラインをそのまま貼り付けて、エフォートのレベルも出してほしいと頼んだ。 そのとき表示されていたのは、次のような内容である。
mdx-playground · master · Opus 5.5 (1M context) · dev :3000 · ⚠ node×26 · /procs
ctx 0% · 5h 13% (45m) · 7d 22% (9/25(金)17:59) · Fable 24% (9/25(金)17:59)
リポジトリとブランチ、モデル名、dev サーバー、走っている node の数、利用量までは並んでいる。 いまどのエフォートで動いているかだけが、どこにも出ていない。
そもそも、その値をステータスラインが受け取れているのか。
Claude Code は、ステータスラインのスクリプトが受け取る入力 JSON に effort が入っているかを確かめるため、デバッグ出力を一時的に足した。
入力 JSON には effort: {level: "high"} が入っていた。
値が届いているなら、あとは表示を足すだけで済む。
デバッグ行を外し、1行目のモデル名のすぐ後ろにエフォートのレベルを出すようにしてもらった。
Claude Code の説明は、次に表示が更新されたときからそう出るはずだ、というものだった。
「コミットしといてください」と頼むと、~/.claude リポジトリに statusline.py の変更だけがコミットされた（f57e91d）。
push はしていない。
1回目のコミットは、コミット前の Codex レビューで止まった。
朝に gpt-6-sol へ切り替えたばかりのフックが、昼には自分のコミットを止める側に回っていた。
yt-dlp の「JavaScript ランタイムが無い」警告
自作の Chrome 拡張は、X 用のほかに YouTube 用も作っている。 その YouTube 用の拡張で動画をダウンロードしようとしたら、次のエラーが返ってきた（動画 ID は伏せた）。
WARNING: [youtube] No supported JavaScript runtime could be found. Only deno is enabled by default; to use another runtime add --js-runtimes RUNTIME[:PATH] to your command/config.
ERROR: [youtube] <動画ID>: This video is not available
警告が1件とエラーが1件である。 何が起きているのか分からず、そのまま Claude Code に貼って「これ何ですか？」と聞いた。
Claude Code は、JS ランタイムの原因を先に特定してから、「動画が利用できない」エラーの切り分けに進んだ。 原因は、拡張のコードではなかった。 yt-dlp が、YouTube の JavaScript チャレンジを解けていなかったのである。 同じ動画で条件を変えて試してもらうと、チャレンジを解ける状態にしたときは取得できた。 動画も公開中だった。
警告の中で案内されていたのは、yt-dlp の EJS に関する wiki で、JS ランタイムの入れ方が書いてある。
deno を上げて、native host から絶対パスで渡す
直し方は、自分で決めた。
deno を上げたうえで、native host から絶対パスで指定する。
警告の文面にも、既定で有効なのは deno だけとあり、RUNTIME[:PATH] の形でパスまで渡せることが示されている。
Claude Code が調べると、YouTube 用の拡張は chrome-extension-youtube という別のリポジトリにあった。
そちらの native host を確認し、deno を 2.9.7 に更新してもらった。
次に、native host が組み立てるのと同じコマンドで、実際にダウンロードできるかを確かめさせた。
同じ動画で、警告もエラーも出ずに mp4 を保存できた。
native host が deno を絶対パスで yt-dlp に渡す形にした変更は、5071d28 としてコミットした。
Codex のレビューで、critical と high の指摘は出なかった。
ダウンロードボタンが消えた件
拡張の再読み込みはしていないが、今回は再読み込みしなくても新しいコードで動く、という説明を受けた。 ところが画面を見ると、ダウンロードボタンが無くなっていた。
Claude Code は、新しいタブでもボタンが出ないことを確かめ、chrome://extensions で拡張そのものが有効になっているかを調べた。 chrome-extension-reload スキルでリロードを試みたが、接続がタイムアウトした。 Chrome 側の許可ダイアログが間に合わなかったらしく、もう1回だけ試した。
ボタンが消えたのは、Claude Code の検証作業が原因だった。 原因になったフォルダはすでに削除したが、拡張の再読み込みは自動ではできなかったので、手で押してほしいという報告である。 手でリロードすると、うまくいった。
再読み込みは要らないと言われた直後に、理由は別とはいえ、結局は再読み込みを押すことになった。
README と Mac 側の手順
直ったところで、該当の拡張のディレクトリにドキュメントを残すよう頼んだ。
README にはもともと「セットアップ」「うまく動かないとき」「経緯」の節があり、そこへ今回の2件を追記してもらった。
追記は c52ab73 としてコミットした。
Codex のレビューは、ドキュメントの追記だけで動作を壊す問題はないという結果で、critical と high の指摘は出なかった。
push してよいと伝えると、5071d28 と c52ab73 の2コミットが origin/master に反映された。
最後に一つ、注意を受けた。
Mac 側で使うときは、git pull だけでは足りない。
deno の更新と yt-dlp-ejs の導入が別に要り、その手順は README の「セットアップ」節に書いてある。
振り返り
三つとも、手を入れる前に一度確かめる手順を挟んでいた。
Codex は gpt-6-sol が実際に呼べるかを確かめ、ステータスラインは入力 JSON に effort が入っているかを見て、yt-dlp は同じ動画で条件を変えて試した。
- Codex のモデル指定は、コミット前のフックとドキュメントレビューで別々に持っていた。更新が漏れていたのは、フックのほうだけだった
- 2台運用では、
git pullで揃うのはリポジトリの中身までである。deno やyt-dlp-ejsのように手元へ入れたものは、Mac 側で別に入れる必要がある