codex-huge-context について
Codex の大規模コンテキスト設定を、OpenAI API への直接推論で構成・監査するスキルです。API キーによる推論とコネクター用の ChatGPT ログインを分離し、Codex 起動前の検証を必須とします。
主な機能
- 01API 直接推論の設定
- 02コンテキストと圧縮の安全制御
- 03モデルカタログの検証
- 04Keychain による認証情報の受け渡し
- 05秘密情報を出さない事前チェック
活用シーン
- 01Codex の大規模コンテキスト設定
- 02プロバイダーとコンテキスト設定の監査
- 03起動前の API 認証情報の確認
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/ / github.com/ steipete/ agent-scripts --skill codex-huge-contextインストール後、Claude Code で/codex-huge-contextを入力して読み込まれたか確認します。
同梱ファイルscripts/preflight.rbscripts/preflight.test.rb
詳細
Codex Huge Context
Codex の 100 万トークンコンテキスト設定を構成、修復、または監査する場合に、このスキルを使用します。意図するトポロジーは、Gmail、Calendar、その他のコネクターの OAuth 用に通常の ChatGPT ログインを維持しながら、API に直接推論リクエストを送る構成です。
Codex inference -> Keychain auth helper -> https://api.openai.com/v1/responses
Codex connectors -> normal ChatGPT login in auth.json
これは HTTP プロキシではありません。アクセス権、実際のモデル制限、課金については、引き続き API が正式な基準となります。
プロバイダーとコンテキストの不可分な不変条件
プロバイダーセレクター、コンテキストウィンドウ、圧縮しきい値、カスタムモデルカタログは、ひとまとまりの構成として扱ってください。Peter の通常の ChatGPT 認証済みセットアップでは、model_provider = "openai" は ChatGPT をバックエンドとする経路を選択します。このスキルの API 直接接続用の 922000 コンテキストウィンドウと 700000 の圧縮しきい値を、その経路に決して割り当てないでください。プロバイダー ID だけでは通信経路は決まりません。API キー認証を使用する組み込みの openai でも、API を使用できます。このスキルとその事前チェックでは、推論に専用の Keychain ヘルパーを使用し、コネクタのログインを別に保つため、以下で指定する openai_api_direct プロバイダーが必要です。
この構成の分離により、小さいプロバイダーまたはモデルメタデータの制限に、700,000 トークンの圧縮しきい値が割り当てられることがあります。また、Codex が要求されたウィンドウを上限で制限する場合もあるため、ルートの数値だけでは使用可能なコンテキストを証明できません。ブラウザーや Computer Use を多用するスレッドでは、圧縮前にプロバイダーの実際の制限を超えて増大し、context_length_exceeded が発生することがあります。その場合、圧縮リクエスト自体が収まらず、圧縮できなくなる可能性があります。ディスク上のファイルだけでなく、新しいセッションで報告される実効ウィンドウも確認してください。
必須の事前チェックでは、この不一致を致命的な問題として扱います。設定を書き換えた後、アプリの設定を変更した後、モデルを変更した後、またはフリート同期を行った後は、事前チェックに合格するまで Codex を起動または再開しないでください。安全でない設定の分離が報告された場合は、model_provider = "openai_api_direct" に戻し、すべての Codex デスクトップ/共有アプリサーバーを再起動して、新しいスレッドを開始するか、フォークしてください。失敗したスレッドを再開すると、記録されたプロバイダーがそのまま保持されます。
安全な入力ウィンドウ
GPT-6 Astra のコンテキストウィンドウは合計 1,050,000 トークンで、最大 128,000 出力トークンを生成できます。Codex は通常の Responses API ターンで出力予算をより小さく設定しないため、カタログには合計値ではなく、安全な入力可能量を記載する必要があります。
1,050,000 total - 128,000 maximum output = 922,000 safe input
両方の直接接続プロバイダーのカタログモデルに、同じ安全な入力ポリシーを適用してください(GPT-6.1 Sol も、同じ 1,050,000 トークンのコンテキストウィンドウと 128,000 トークンの出力上限を備えています)。
gpt-6-astragpt-6.1-sol
コンテキストを設定するときは、オペレーターが選択した、サポート対象のモデルを維持してください。以下の例では Astra を使用しています。大規模コンテキストを有効にしても、別の選択済みモデルへの置き換えが許可されるわけではありません。
Codex は 922,000 トークンの入力可能量に通常の 95%の実効ウィンドウ余裕分を適用するため、使用可能なトークン数は約 875,900 と報告され、保護されます。自動圧縮は、アクティブなトークン総数が 700,000 に達したときに行うよう設定してください。これにより、Codex の実効保護範囲内に約 175,900 トークン、次のプロンプト、ツールスキーマと結果、指示、シリアライズのオーバーヘッド、圧縮自体のために、プロバイダーの安全な入力上限まで 222,000 トークンの余裕が残ります。この余裕を大きくしているのは意図的です。Codex 0.144.6 は、次のユーザーメッセージとコンテキストの更新を追加する前に、すでに記録されたコンテキストを確認します。また、しきい値を超える最終応答があっても、次のターンまで圧縮されない場合があります。大規模コンテキストを使用したワークロードでは、1 ターンで約 144,000 トークン増加したことがあり、以前の 820,000 というしきい値は攻めすぎていました。
入力トークン数が 272,000 を超える長文コンテキストのリクエストには、プロバイダーの長文コンテキスト向けの高い料金が適用されます。この経路が不要なワークロードで、誤って有効にしないでください。
必須ファイル
~/.codex/models-api-1m.json には、各モデルエントリーの残りの内容を維持したまま、5 つすべてのモデルスラッグについて次の値を含める必要があります。
{
"context_window": 922000,
"max_context_window": 922000,
"auto_compact_token_limit": 700000
}
Codex のデフォルトである 95% を使用するには、effective_context_window_percent を設定せずにおきます。または、整数の 95 を明示的に設定します。Null、浮動小数点数、その他の値は無効です。
インストール済みの Codex リリースに含まれる完全なネイティブカタログを、レビュアーモデルも含めて使用してください。カスタムカタログは選択したエントリーを上書きするのではなく、組み込みカタログを置き換えます。すべてのモデルについて、実際のメタデータと最小バージョンを満たすクライアントを使用してください。指示、ツール機能、および必須のレビュー動作を含むすべての安全フィールドを維持し、上記のコンテキストフィールドとコンパクションフィールドのみを上書きしてください。Astra のメタデータを捏造したり、Sol のエントリーを Astra として表示したりしないでください。上記の API コンテキスト契約は、プロバイダーを直接指定するオーバーライドに対応するものであり、ChatGPT の利用資格を拡大したり、クライアントの安全要件を緩和したりするものではありません。プリフライトで検証するのはコンテキストと認証情報の受け渡しであり、カタログ内の残りのメタデータの出所ではありません。
カタログには、各モデルの安全な最大値が記載されています。セッションのデフォルトは 500,000 トークンのウィンドウです(Peter、2026-10-12)。コンテキストが 100k から 300k に増えるとステップの遅延はおよそ 2 倍になるため、必要な場合を除き、各レーンではより小さい値を使用します。~/.codex/config.toml のルートセクションには、次の設定が必要です。
model = "gpt-6.1-sol"
model_provider = "openai_api_direct"
model_context_window = 500000
model_auto_compact_token_limit = 400000
model_auto_compact_token_limit_scope = "total"
model_catalog_json = "/Users/steipete/.codex/models-api-1m.json"
[model_providers.openai_api_direct]
name = "OpenAI API direct"
base_url = "https://api.openai.com/v1"
wire_api = "responses"
requires_openai_auth = false
supports_websockets = true
[model_providers.openai_api_direct.auth]
command = "/Users/steipete/.codex/bin/fetch-openai-inference-key.zsh"
timeout_ms = 5000
refresh_interval_ms = 300000
必須の supports_websockets = true を設定してください。カスタムプロバイダーはデフォルトで HTTP を使用し、各ステップでプロンプト全体を再アップロードします(2026-10-12 に、アップリンク約 22 Mbps、コンテキスト 150k で測定したところ、HTTP では 1 ステップあたり 26~59 秒だったのに対し、WebSocket では 0.8~3.7 秒でした。WebSocket の継続リクエストでは新しい項目のみが送信されます)。
ルートにある model_context_window = 1050000 や 922000 などの古い値は置き換えてください。ルートキーを重複して残さないでください。安全予算はコンパクション後のプレフィックス以降に追加された内容だけでなく、アクティブなリクエスト全体に適用されるため、スコープは total のままにしてください。
プロファイル
Codex 0.162 では、プロファイルはファイルです。codex -p <name> は ~/.codex/<name>.config.toml をベース設定に重ねて適用します(名前に使用できるのは英字、数字、_、- のみです)。各ホストには次の 4 つがあります。
| プロファイル | model | コンテキスト |
|---|---|---|
astra | gpt-6-astra | ベース 500k |
sol61 | gpt-6.1-sol | ベース 500k |
astra-1m | gpt-6-astra | 922000 ウィンドウ、700000 コンパクション、スコープ total |
sol61-1m | gpt-6.1-sol | 922000 ウィンドウ、700000 コンパクション、スコープ total |
各プロファイルでは、model_provider = "openai_api_direct" も設定します。コンテキストキーを設定するプロファイルでは、必ずこのプロバイダーを固定し、500000/400000 または 922000/700000 を使用してください。プリフライトでは、すべての *.config.toml に対してこれを強制します。リポジトリ全体のコンテキストが必要な作業に限り、-1m プロファイルを使用してください。
ホストを変更する前に、両方の設定ファイルを日付入りの同じディレクトリ内のファイルにバックアップしてください。無関係なプロジェクト、プラグイン、MCP、通知、承認、モデル選択、または推論の設定は置き換えないでください。
API 認証情報の受け渡し
認証コマンドは専用の Keychain 受け渡し用コピーを読み取ります。TOML 内の値や環境変数は使用しません。
#!/bin/zsh
set -euo pipefail
exec /usr/bin/security find-generic-password \
-a Codex \
-s "Codex OpenAI inference API" \
-w /Users/steipete/Library/Keychains/login.keychain-db
インストール時に、ホストで実際に使用されている Keychain のパスを特定して検証してください。この例はホスト固有です。その絶対パス(秘密情報ではありません)は外部実行ファイル内に保持し、$HOME/~、プロバイダーのオーバーライド、または空でない auth.args には保存しないでください。管理対象の自動レビューでは、クライアントの HOME/USERPROFILE と XDG の config/data/state/cache ディレクトリが置き換えられます。そのため、暗黙的な Keychain の選択では、親セッションからの受け渡しが成功する場合でも、終了コード 44(SecKeychainSearchCopyNext の項目が見つからない)が返ることがあります。レビュー担当者の HOME、ファイルシステムへの許可、認証情報へのアクセスではなく、ラッパーの Keychain 選択を修正してください。既存のヘルパーを変更する前に確認してください。すでに明示的な選択を使用している場合があります。
API キーを扱う前に $one-password を使用してください。正規の値は、Molty の AI API Key - OpenAI - OPENAI_API_KEY - Serviceable Access 項目にある OPENAI_API_KEY フィールドです。共有の op-work tmux セッション内でサービスアカウントのワークフローを通じて読み取り、Keychain のコピーのみを保存または更新してください。決して表示したり、SSH 経由でコピーしたり、プロファイルに記載したり、一時ファイルに書き込んだりしないでください。
Keychain 項目では /usr/bin/security を許可してください。Keychain の読み取り時に通常はプロンプトは表示されません。再起動後にログイン Keychain がロックされている場合、または非対話型 SSH 経由でコマンドを起動した場合、エラー 36(User interaction is not allowed)で失敗することがあります。平文ファイルや長期間稼働する秘密情報デーモンでこの失敗を回避しないでください。ホストをローカルのグラフィカルセッションからロック解除し、そこで項目をインストールしてから、そのローカルセッションで Codex を使用してください。
設定済みのマシンで Codex を初めて新規起動または再開する前に、秘密情報を安全に扱う事前チェックを実行してください。認証情報やヘルパーの stderr を表示せずに、直接プロバイダーの設定、安全な入力値と圧縮値、カタログの 5 項目すべて、ヘルパーの実行可能性、およびヘルパーから受け渡される値が空でないことを検証します。
ruby ~/.codex/skills/agent-scripts/codex-huge-context/scripts/preflight.rb
これが失敗した場合は、ロールアウトを完了としたり、Codex を起動したりしないでください。requires_openai_auth = false の場合、Keychain の受け渡し用コピーが見つからなくても、通常の Codex ログインにはフォールバックできません。直接プロバイダーはベアラーヘッダーなしで api.openai.com/v1/responses にアクセスし、不透明な HTTP 401 を返すことがあります。事前チェックなら、必要なブートストラップ作業をより早い段階で示します。GITHUB_PAT_TOKEN が未設定であるという警告は独立したもので、推論には影響しません。GitHub MCP の同時起動失敗の説明にはなりますが、OpenAI API の認証と混同しないでください。
事前チェックにおけるプロバイダーの確認は、見せかけのものではありません。直接プロバイダーのテーブルと 100 万トークンのカタログが存在していても、ルートの model_provider = "openai" が設定されたマシンは、他の数値がすべて正しくても動作しません。
管理対象の自動レビューでの受け渡し
この名前付きルートを使用した分離レビューの前に、プライベートホームディレクトリで外部ヘルパーも確認してください。
ruby ~/.codex/skills/agent-scripts/codex-huge-context/scripts/preflight.rb --private-home
このオプトイン診断では、まず親コンテキストを検証し、次に同じ信頼済みヘルパーを、新しい HOME/USERPROFILE と XDG の config/data/state/cache ディレクトリで呼び出します。ヘルパーの出力はメモリ内で取得して破棄します。認証情報をファイルや環境変数にコピーすることはありません。その他の環境設定と作業ディレクトリは引き継がれます。これは、サニタイズされたレビュー担当者環境全体を再現するものでも、サンドボックスのテストでも、推論の実証でもありません。
意図した固定済み Git ターゲットで、--codex-config 'model_provider="openai_api_direct"' を指定し、意図したモデルを変更せずに、実際の $autoreview を実行して完了してください。ソースのスキャン、認証の投影、サンドボックス化、およびすべてのツールに対する認証情報の拒否を維持してください。既存の Keychain 受け渡し用項目を読み取れるのは、クライアント側の認証コマンドだけです。レビュー担当者のツールに実際の認証情報を取得させてテストしてはいけません。明示的な選択でも失敗する場合は、秘密情報を安全に扱った正確なステータスを報告して中止してください。プロバイダーへのフォールバック、実際の HOME の引き継ぎ、秘密情報のファイル/環境変数経由の受け渡し、認証情報ブローカー、サンドボックスの例外は認められません。
ChatGPT コネクタへのログイン
requires_openai_auth = false が適用されるのは、カスタム推論プロバイダーだけです。ChatGPT に接続するプラグインを動作させるには、Codex のルートログインを ChatGPT 認証のままにする必要があります。
codex login status
API キーでログインしていると表示され、ホストで Gmail、Calendar などのコネクタが必要な場合は、ローカルユーザーのセッションから codex logout を実行してから codex login を実行してください。Mac 間で auth.json や OAuth トークンをコピーしないでください。
新規、再開、共有サーバーのセッション
-m gpt-6-astra はモデルを選択するものであり、プロバイダーを選択するものではありません。新規セッションではルートの model_provider が読み込まれ、その後、セッションのメタデータに選択されたプロバイダーが記録されます。セッションを再開すると、記録済みのプロバイダーが引き継がれます。
Codex TUI セッションでは、~/.codex/app-server-control/app-server-control.sock を再利用することがあります。共有アプリサーバーは起動時に読み込んだ設定を保持するため、ディスク上のファイルを変更しても、古いサーバーに接続しているセッションには反映されません。コンテキストまたは認証設定を変更した後は、次の手順を実行してください。
- アクティブなターンが完了するまで待ちます。
- Codex デスクトップアプリと、共有 CLI アプリサーバーを再起動します。
- 最終確認のため、新規セッションを開始します。
- 記録済みのモデル/プロバイダーを維持する意図がある場合に限り、古いセッションを再開します。
codex -c 'model_provider="openai_api_direct"' のように、同じ値で CLI オーバーライドすると、呼び出しごとに組み込みのアプリサーバーが強制的に使用されます。これはプロバイダーやサービス階層を変更せずに診断する際に役立ちますが、フリート展開における恒久的な解決策ではありません。
フリート展開
まず $fleet-maintenance と $remote-mac を使用してください。~/Projects/manager/computers.yaml を読み込み、稼働中の Tailscale の状態を使用して、ハードウェア UUID で重複を排除し、引き渡し済みのホストを除外します。変更を加える前に、接続可能なすべてのホストを監査してください。変更は一度に 1 台のホストに対して行います。
Peter の現在の個人用 Mac の対象範囲は、MacBook Pro、ロンドンとサンフランシスコ 2 台の Mac Studio、別所有の SF Mac Mini(mac-mini-sf / steipete-mini-sf)、ClawMac、FoundationClaw、MegaClaw、MiniClaw です。FoundationClaw のプロバイダーアカウントと Mac14,12 のハードウェア ID は確認済みですが、以前機能していた認証情報についてプロバイダー側でのリセットが必要です。リセット後、Tailscale への登録、正規チェックアウト、および残りのワーカーのブートストラップを続行できます。SF Mac Mini では、信頼済みの SSH/アカウント経路が未確認です。MiniClaw の正規 Tailscale ID は miniclaw です。リモートファイルを変更する前に、各ホストの ID と agent-scripts のチェックアウトを確認してください。ホストごとに、次の結果を記録してください。
- 設定とカタログのバックアップ
- ルートの安全な入力値、コンパクションしきい値、スコープ
- カタログの 5 つのエントリーすべてと、それぞれのコンテキスト値
- 意図したローカルユーザーのセッションでの事前確認結果
- 認証情報を表示せずに取得した
codex login status - 直接 API のプローブ結果
- 共有アプリサーバーのバージョンと、再起動が保留中かどうか
通常、agent-scripts スキルのチェックアウトは ~/.codex/skills/agent-scripts から参照できます。このスキルをプッシュした後、対象となる ~/Projects/agent-scripts のチェックアウトのみを早送りしてください。アクティブなチェックアウトや変更のあるチェックアウトをリセット、スタッシュ、上書きしたり、設定を再読み込みするためだけにアクティブな Codex のターンを中断したりしないでください。その場合は保留として報告してください。
検証
意図したローカルユーザーのセッションで、次のコマンドを実行してください。
ruby ~/.codex/skills/agent-scripts/codex-huge-context/scripts/preflight.rb
codex login status
jq -r '.models[] | select(.slug == "gpt-6-astra" or .slug == "gpt-6.1-sol") | [.slug, .context_window, .max_context_window, .auto_compact_token_limit] | @tsv' ~/.codex/models-api-1m.json
codex exec --skip-git-repo-check 'Reply with exactly: direct-api-safe-context-ok' </dev/null
次に、各プロファイル(codex exec --skip-git-repo-check -p <name> ...)をプローブし、新しい展開の task_started イベントから model_context_window を読み取ってください。基準プロファイル、astra、sol61 は 475000、astra-1m と sol61-1m は 875900 です。
事前確認の成功、すべてのカタログモデルでの 922000、922000、700000、コネクタに対応するホストでの ChatGPT ログイン、およびプローブの完全一致応答を確認してください。直接 API プローブの成功は、コネクタの OAuth が機能することの証明にはなりません。別途 codex login status を確認してください。
最終的な TUI の確認では、プロンプトのテキスト送信と Enter キーの送信を、別々のターミナル操作として行ってください。エコーされた入力をモデルの応答として扱わないでください。
障害発生時の対応方針
- 事前チェックで安全でない分割設定が報告された場合:このスキルの
openai_api_directプロバイダー契約を復元してください。直接ルートのしきい値を下げたり、922K/700K のオーバーライドを Peter の ChatGPT に接続されたopenaiルートに残したりしないでください。すべてのアプリサーバーを再起動し、新規またはフォークしたスレッドを使用してください。既存のセッションメタデータには以前のプロバイダーが保持されているためです。 - API レスポンスでリクエストが引き続き制限または拒否される場合:サーバーのレスポンスを記録してください。クライアントカタログのオーバーライドによってサーバー側の利用権限が変更されたと主張しないでください。
- 有効トークン数が 700,000 未満でコンテキストオーバーフローが発生した場合:セッションファイルを保持し、しきい値をさらに下げる前に、直近のトークン計数イベントを調査してください。
- コンパクションなしで有効トークン数が 700,000 を超えてからコンテキストオーバーフローが発生した場合:実行中のアプリサーバーのバージョンと読み込まれた設定を確認してください。古いサーバーでは以前のしきい値が保持されていることがあります。
- HTTP 401
Missing bearer or basic authentication in headerが発生した場合:事前チェックを再実行し、Keychain からの受け渡しを修復してください。プロバイダーや通常の Codex 認証に切り替えないでください。 - リモート環境で Keychain エラー 36 が発生した場合:安全な設定を適用待ちの状態に保ち、ローカルでの GUI アンロックを必須としてください。シークレットの保存方法を決して弱めないでください。
- ルートの API キーでログイン済みでもコネクターが必要な場合:ローカルユーザーに ChatGPT へのログインを完了するよう依頼してください。推論には引き続き直接プロバイダーを使用できます。
- 既存の
openai_api_directプロバイダーがこの契約と異なる場合:変更する前に内容を確認してください。TOML テーブルを重複して追加しないでください。