Codexのunknown variant defaultエラー修正：service_tierは削除か更新¶
対象: service_tierのinvalid configurationで新規スレッドが始まらない人
次のエラーで新しいスレッドが始まらない場合、fastやflexを適当に選ばない。
invalid configuration: unknown variant `default`,
expected `fast` or `flex` in `service_tier`
まずconfig.tomlに自分で書いたservice_tier = "default"があれば、その行をバックアップ後に削除する。設定がない、または削除しても再現する場合は、Codex Desktopと同梱app-server / モデル情報の版ずれを疑い、Desktopアプリ本体を更新して完全再起動する。
この記事のポイント¶
- 明示した
service_tier = "default"は一度外して切り分ける - 設定行がなければDesktop同梱app-serverの版ずれを疑う
- エラー回避だけを目的に
fastやflexへ変更しない
なぜdefaultが拒否されるのか¶
公式CodexリポジトリのIssue #27297では、Desktop更新直後に同じエラーが発生し、ユーザーのconfig.tomlにservice_tierがなくても再現した。報告環境では、Desktop同梱の古いapp-serverと、別途更新されたCLIやモデル情報の世代が一致していなかった。1
一方、Codexリポジトリの現行config.schema.jsonでは、service_tierは新しいターンに送る任意設定で、default、priority、flex、互換用fastが例示されている。2
つまり、このエラーは「defaultという考え方が常に誤り」という意味ではない。値を作った側と解釈する側の版がずれている可能性が高い。
復旧手順¶
1. 設定ファイルをバックアップする¶
通常のCLI設定は$CODEX_HOME/config.toml、CODEX_HOME未設定なら~/.codex/config.tomlにある。
cp ~/.codex/config.toml ~/.codex/config.toml.bak
rg -n '^service_tier\s*=' ~/.codex/config.toml
Windowsでは、実際にCodexが使っているCODEX_HOMEを確認し、エディタで同じ行を探す。パスが分からない場合は、推測で別の.codexを編集しない。
2. 明示したdefaultをいったん削除する¶
次の行が自分の設定にある場合だけ、コメントアウトまたは削除して再起動する。
service_tier = "default"
service_tierは任意設定なので、行を消せばアプリ側の既定選択に戻る。fastやflexへの置換は、エラーを黙らせるための中立な変更ではない。速度、利用条件、課金特性に関わる選択になり得るため、意図がある場合だけ公式設定説明に従って使う。
3. Codex Desktop本体を更新する¶
設定行がないのに再現する場合、ターミナルのCLIだけを更新しても不十分だ。Desktopが起動するのは、アプリ内に同梱された別のCodex/app-serverであることがある。
- Codex Desktopの更新機能または配布ストアでアプリを更新する
- アプリを完全終了し、残留プロセスがない状態で起動する
- 新しいスレッドで再テストする
macOSでは、必要ならDesktop同梱バイナリとターミナル側を分けて確認できる。
/Applications/Codex.app/Contents/Resources/codex --version
codex --version
番号が違うだけで必ず障害とは限らない。しかし、エラー直後に同梱側だけ古い場合は、版ずれの有力な手掛かりになる。
4. 診断結果の意味を取り違えない¶
codex doctor --summary
このコマンドが成功しても、Desktop同梱app-serverが正常とは限らない。ターミナルのcodexとDesktopが別のバイナリを使っている場合、片方だけ正常ということがある。
直らない場合に確認するもの¶
次の4点を記録して、公式Issueの既存報告と比較する。
- エラー全文
- Codex DesktopのAboutにあるビルド番号
- ターミナル側の
codex --version config.tomlにservice_tierが存在するか
モデル選択画面も同時に使えない場合は、その事実も重要だ。Issue #27297でも、service_tierエラーとモデル選択不能が同時に報告されている。1
避けるべき対処¶
- とりあえず
fastへ変える: 利用特性を変える設定であり、互換性問題の根本解決ではない - とりあえず
flexへ変える: 同様に、意図しないサービス階層を選ぶ可能性がある .codex全体を削除する: 会話状態や認証情報まで失うリスクがあり、同梱版が古ければ再発する- CLIだけ更新して完了と判断する: Desktopは別の同梱バイナリを使う場合がある
- モデル名を固定して回避する: モデルカタログとparserの不整合を隠すだけになり得る
よくある質問¶
service_tier = \"default\"は今も無効？
現行の公式設定スキーマではdefaultが例示されている。問題は、古いparserが新しい値を読んだ場合の互換性だ。エラーが出る環境では明示行を外し、アプリ一式を更新する。
設定にservice_tierがないのに、なぜエラーになる？
Desktopの保存状態、モデル情報、app-server間で値が渡される経路がある。公式Issueでも、ユーザー設定に行がない状態で同じエラーが再現している。
fastとflexのどちらにすればいい？
エラー回避だけを目的に選ばない。まず設定を未指定へ戻し、Desktopの版を揃える。サービス階層を明示する必要がある場合だけ、現在の公式説明と契約条件で判断する。
まとめ¶
- 明示した
service_tier = "default"があれば、バックアップ後にその行を外す - 設定がなくても再現するなら、Desktop同梱app-serverとモデル情報の版ずれを疑う
- Desktop本体を更新して完全再起動し、CLIとDesktopを別々に確認する
fastやflexへの強制変更、.codex全削除は最初の対処にしない