Codex CLI エラー集：ログイン失敗・サンドボックス拒否・MCP・Windows・モデル指定

Codex CLIが動かないときは、最初に codex doctor --summary を実行し、次に codex login status、それでも分からなければ -c key=value で設定を一時的に上書きして再現する——この順番で、config.toml を書き換えずに原因へたどり着けます。この記事は筆者のWindows環境(Codex CLI 0.144.1、ChatGPTアカウント)で実際に出したエラーと、公式ドキュメントの記載を症状別に並べたものです。

導入手順そのもの(インストール、AGENTS.md、認証方式の決め方)はCodex CLI 導入ガイドに書いてあります。ここでは「入れたのに動かない」以降だけを扱います。

最初にやる3手

codex doctor --summary      # 16 ok · 1 idle · 3 notes · 1 warn · 0 fail のような集計が出る
codex login status          # Logged in using ChatGPT
codex -c model="gpt-5.5" -s read-only -a never exec "reply with the single word OK"

3つ目は最小構成の疎通テストです。読み取り専用サンドボックス・承認なしで1ターンだけ回し、モデルまで届くかを見ます。

1. ログインできない(ChatGPTアカウント / APIキー)

公式Authenticationページの手順は3通りです。

# ブラウザが開く環境
codex login

# ブラウザが開けない環境(サーバー、コンテナ、WSLなど)
codex login --device-auth

# APIキー(標準入力から渡す。引数に直接書かない)
printenv OPENAI_API_KEY | codex login --with-api-key

codex login --help の出力にも --with-api-key(stdinから読む)、--with-access-token、--device-auth が並んでいます。

よくある症状と原因

• ブラウザが開かず先へ進めない: SSH越しやWSL内で起きます。公式の推奨はデバイスコード認証(--device-auth、ベータ。組織側で許可が必要)。代替として ssh -L 1455:localhost:1455 user@remote でポート転送してから codex login、またはローカルの ~/.codex/auth.json をリモートへコピーする方法が公式に載っています。
• ログインしたはずなのに毎回求められる: 認証情報は ~/.codex/auth.json(平文)またはOSの資格情報ストアに保存されます。config.toml の cli_auth_credentials_store(file / keyring / auto / ephemeral)が ephemeral になっていないか、CODEX_HOME を変えていないかを確認します。
• APIキーでログインしたのにプランの機能が使えない: 公式Pricingページでは、APIキー利用は従量課金で、GitHubコードレビューやSlack連携などのクラウド機能は対象外です。プランの枠を使うなら codex logout してChatGPTで入り直します。
• 組織でログイン方法が固定されている: forced_login_method = "chatgpt" / "api" と forced_chatgpt_workspace_id で管理者が固定できます。

2. サンドボックス・権限(approval mode)で止まる

Codexの権限は approval_policy(いつ人に聞くか)と sandbox_mode(何ができるか)の2軸です。公式のAgent approvals & securityページとConfiguration Referenceの値を引きます。

症状別の見方

• コマンドが「permission denied」相当で失敗し、承認も出ない: sandbox_mode = "read-only" のまま書き込みを試みているか、approval_policy = "never" で失敗がそのままモデルに返っています。codex --help によれば never は「Execution failures are immediately returned to the model」。対話で使うなら on-request に戻します。
• ネットワークが必要なコマンド(npm install等)だけ失敗する: workspace-write はネットワークが既定で閉じています。公式の設定例は次の形です。

sandbox_mode = "workspace-write"

[sandbox_workspace_write]
network_access = true
writable_roots = ["/Users/YOU/.pyenv/shims"]   # 追加で書き込みたい場所

• approval_policy = "untrusted" で警告や無視: 公式は「Codex and ChatGPT Work no longer support approval_policy = “untrusted”」とし、読み取り専用の対話には on-request + read-only を案内しています。筆者環境の0.144.1では --help に untrusted が残っていましたが、消える前提で書き換えておくのが安全です。
• Linux / WSL2で起動時に警告が出る: サンドボックスに bubblewrap を使うため、bwrap が無いかユーザー名前空間を作れないと警告が出ます。Ubuntu 24.04ではAppArmorが原因になることがあり、公式は bwrap 用のプロファイルを読み込む方法を案内しています。
• どの権限で動いているか分からない: 対話中は /status、切り替えは /permissions。codex exec の出力冒頭にも approval: on-request sandbox: read-only と現在値が印字されます。

3. MCPサーバーが繋がらない

MCPまわりの既定値は公式Configuration Referenceで決まっています。

存在しないコマンドをMCPサーバーとして登録し、required = true を付けて起動すると、次の出力で終了しました(exit 1)。

ERROR codex_core::session: Failed to create session: required MCP servers failed to initialize: badserver: program not found
Error: thread/start: thread/start failed: error creating thread: Fatal error: Failed to initialize session: required MCP servers failed to initialize: badserver: program not found (code -32603)

同じ設定で required を付けない場合、codex exec は何も表示せずに起動し、モデルの応答まで正常に返りました。required を付けていないMCPサーバーの失敗は、非対話モードでは目に見えないということです。「ツールが無い」と感じたら、まず一覧で状態を確認します。

codex mcp list        # Name / Command / Args / Env / Cwd / Status / Auth の表
codex mcp get <name>  # 1件の詳細
codex mcp login <name>  # OAuth が必要な streamable HTTP サーバー

筆者環境の codex mcp list では、stdioサーバーはCommand列にフルパスのexe、HTTPサーバーはUrl列と「Bearer token」「Not logged in」のようなAuth列が出ました。

症状別の原因

• program not found: command がPATHに無いか、Windowsでシェル経由の解決(npx など)を期待しています。筆者環境の設定はすべて実行ファイルのフルパスで書かれていました。cwd で相対パスの解決先を固定する手も公式にあります。
• 起動はするがすぐタイムアウト: 初回に依存を落とすサーバーは10秒に収まりません。startup_timeout_sec = 120 のように個別に伸ばします。
• HTTPサーバーが「Not logged in」: codex mcp login <name> でOAuthを通します。bearer_token_env_var の環境変数がCodexの起動シェルに存在するかも確認します。
• ツールが多すぎて無視される: enabled_tools / disabled_tools で絞れます。サーバー説明文は先頭512文字で自己完結させるよう公式が求めています。

MCPそのものの疎通確認(JSON-RPCを手で叩く方法)はMCPサーバーが繋がらない時の切り分けとstdioでMCPサーバーをテストするにまとめてあります。

4. Windowsで動かない(WSLは必須か)

2026年4月時点の当サイトの導入ガイドは「Windows 11 via WSL2」を要件として書いていましたが、2026年9月の公式ドキュメントではネイティブWindowsが正式な実行環境になっています。Windows sandboxページの要点は次の通りです。

• PowerShellから直接動き、windows.sandbox = "elevated"(推奨。専用の低権限ユーザー・ファイルシステム境界・ファイアウォール規則)と "unelevated"(ACLベースのフォールバック。隔離は弱い)の2モード
• Windows 11推奨、Windows 10はv1809以降でベストエフォート。winget が必要で、初回セットアップに管理者承認が要ることが多い
• Error 1385 は「Windows is denying the logon type the sandbox user needs in order to start the command」。サンドボックスユーザーのログオン権限をIT部門に確認する
• IDE拡張が無反応なら Visual Studio Build Tools(C++ワークロード)と VC++ 再頒布可能パッケージ(x64)を入れる

筆者の config.toml にも [windows] sandbox = "elevated" が入っており、codex doctor は「sandbox restricted fs + restricted network · approval OnRequest」と報告しました。codex sandbox <command> で任意のコマンドをそのサンドボックス内で試せます。

WSL2を選ぶ条件は、公式WSLページの言葉を借りると「Linuxネイティブのツールが必要」「開発フローがすでにWSL2にある」「ネイティブのサンドボックスがどちらも動かない」のいずれかです。

# WSL2 側でのインストール(公式)
curl -fsSL https://chatgpt.com/codex/install.sh | sh
codex

# 遅いとき: /mnt/c 配下で作業していないか確認し、~/code/ 以下へ移す
# WSL 自体の更新
wsl --update
wsl --shutdown

「Codex CLI not found」なら which codex で入っている場所を確認して再インストール、というのが公式の案内です。

5. モデル指定エラー

筆者環境で2種類の400エラーを再現しました。どちらも codex exec の出力です。

# 存在しない / 使えないモデルを -m で指定
warning: Model metadata for `nonexistent-model` not found. Defaulting to fallback metadata; this can degrade performance and cause issues.
ERROR: {"type":"error","status":400,"error":{"type":"invalid_request_error","message":"The 'nonexistent-model' model is not supported when using Codex with a ChatGPT account."}}

# config.toml の model が、手元のCLIより新しい
warning: Model metadata for `gpt-6-astra` not found. Defaulting to fallback metadata; this can degrade performance and cause issues.
ERROR: {"type":"error","status":400,"error":{"type":"invalid_request_error","message":"The 'gpt-6-astra' model requires a newer version of Codex. Please upgrade to the latest app or CLI and try again."}}

2つ目は、筆者の config.toml に書いてあるモデルを、npmで入れた古いCLI(0.144.1)から呼んだときのものです。デスクトップアプリ側は新しく、CLIだけ取り残されていました。codex doctor --summary の「↑ updates 0.154.0 available」がそのまま答えでした。

• 直し方: codex update(codex --help に載る公式サブコマンド)か、npm経由なら npm install -g @openai/codex@latest。更新できない環境では -m gpt-5.5 のように、その版が知っているモデルへ一時的に落とします。
• 「Model metadata … not found」だけの警告: エラーではなく既定メタデータで続行しています。コンテキスト長の扱いがずれるので放置しません。
• 起動時の failed to load models cache: missing field ...: 筆者環境で一度観測。新しいアプリが書いたモデルキャッシュを古いCLIが読めない形で、更新で解消する類のものです(公式記載は未確認)。

6. レート制限・使用量上限

公式Pricingページの記載を要約します。

• ChatGPTのFree / Go / Plus / Pro / Business / Enterprise・EduでCodexが使え、ローカル(CLI・IDE)とクラウドのチャットは同じプラン枠を共有します(「Local messages and cloud chats share your plan’s usage allowance」)
• 上限はプランとモデルで変わり、例としてPlusでGPT-5.6 Lunaを使う場合「250-2,000」ローカルメッセージ/5時間が示されています
• ターンの途中で上限に達しても、そのターンはフェアユースの範囲で続行されます
• 上限後はクレジット(モデルごとのトークン単価、例: GPT-5.6 Solは入力100万トークン100クレジット・出力500クレジット)で延長するか、APIキー(従量課金)に切り替えます

対話中の残量は /status(「Display session configuration and token usage」)で見ます。上限に達したときにCLIが表示する正確な文言は、筆者環境で再現できていないため本記事には載せません。

同じ「上限に当たったらどうするか」を Claude Code 側で整理したのがClaude Codeの使用上限とPro/Max別の枠で、両方使う人は読み比べると設計が似ていることが分かります。

まとめ

• 切り分けは codex doctor --summary → codex login status → -c での一時上書き。config.toml を先にいじらない
• ログインは codex login / --device-auth / --with-api-key(stdin)。auth.json はパスワード扱い
• 権限は approval_policy(on-request / never)と sandbox_mode(read-only / workspace-write / danger-full-access)。workspace-write でもネットワークは既定で閉
• MCPは required の有無で挙動が変わる。非対話モードでは任意サーバーの失敗が見えないので codex mcp list で状態確認
• Windowsはネイティブ実行が正式ルートで、WSL2はLinuxツールが要るときの選択肢。Error 1385はログオン権限
• 「requires a newer version of Codex」はCLIが古いだけ。codex update で直る

筆者が今回いちばん時間を使ったのは、設定ファイルでもMCPでもなく「npmで入れたCLIが3リリース分古かった」ことでした。エラー文にモデル名が出たら、まずバージョンを疑う——config.tomlの調整はその後で十分です。設定キーの一覧はconfig.toml 逆引きリファレンスにまとめています。