codex-windows-fast-patch

Codex Windows Fast Patch

ユーザーが、Codex Desktop のアップグレード後に Fast Mode／Plugins／Goal のパッチが消えたと言う場合、Windows で Codex にパッチを再適用するよう依頼する場合、Fast Mode が実際に送信されているか確認するよう求める場合、ローカルのプラグインマーケットプレイスの復元や登録を求める場合、Codex Desktop で Chrome ブラウザーの使用または Windows Computer Use の有効化を求める場合、またはサードパーティ製モデル／API キーへのアクセスを維持したまま、スマートフォンからのリモート操作を有効化または修復するよう求める場合に、このスキルを使用してください。また、カスタムプロバイダーまたは /v1/models に新しいモデルが表示されるのに Desktop では表示されない場合、GPT-5.6 Sol／Terra／Luna がモデル選択画面に表示されない場合、Statsig の available_models フィルタリングによって必要なモデルの組み合わせが除外され、コンパクトな青紫色の Power スライダーが従来の Model／Reasoning／Speed メニューに戻る場合、またはサードパーティプロバイダーが ChatGPT アカウントのユーザー設定を読み込めないため、「Ultra in model picker slider」設定が表示されているのに無効になっている場合にも使用してください。言語／ロケールの設定が再起動後に元に戻る場合、利用可否のゲートによってブラウザーやプラグインの項目が非表示になる場合、Computer Control 設定ページで、組織または現在の地域で利用できないことが原因で「Any App」／「任意应用」が無効と表示される場合、Computer Use のタスクでネイティブパイプ、バンドルされたプラグインキャッシュ、ヘルパーパス、パッケージインポート、またはランタイム初期化のエラーが報告される場合、cua.getState() とネイティブパイプは動作するのに Computer Use の会話から cua.getApp／cua.listApps が失われ、その症状が Desktop の再起動後に毎回再発する場合、cua.computer.list_windows() は動作するのに Native app bindings are unavailable for windows. で Computer Use の呼び出しが失敗するか、アプリ内ブラウザーのタブでタイムアウトする場合、スマートフォンのリモート操作で QR コードのペアリングが進まない／失敗する場合、ペアリング後にスマートフォンから作成したターンが誤ったモデル API エンドポイントに送信される場合、Desktop で新しいチャット／スレッドの開始が missing field inputSchema で失敗する場合、model_provider／API アカウントの切り替え後にローカルの会話が消える場合、復元された会話は表示されるものの現在の作業ディレクトリが見つからず続行できない場合、またはバンドルされたカスタム model_instructions_file プロンプトアセットの設定を明示的に依頼された場合にも使用してください。

プラットフォームの互換性

このスキルは Windows 専用です。Windows Store／MSIX パッケージのレイアウト、PowerShell、Get-AppxPackage、makeappx.exe、signtool.exe、Windows ユーザー環境変数、および Windows Computer Use ヘルパーのパスに依存します。

macOS ではこのスキルを実行しないでください。macOS への対応には、Codex .app バンドル、ASAR の抽出と再パッケージ化、macOS のコード署名または検疫への対処、シェルスクリプト、および macOS 固有の Computer Use の利用可否に対応する別のワークフローが必要です。

スキルのルートディレクトリ

このドキュメント内のすべてのコマンドでは、スキルのディレクトリを $SkillRoot として参照します。何かを実行する前に、セッションごとに一度だけ解決してください。このスキルは、どのハーネスから読み込まれたかを問いません。そのため、プローブは ~/<agent-home>/skills/<skill-name> のレイアウトに従う任意のエージェントホームに一致します。

$SkillRoot = $env:CODEX_WIN_FAST_PATCH_SKILL_ROOT
if (-not $SkillRoot) {
  $SkillRoot = (Get-ChildItem -Force -Path "$env:USERPROFILE\.*\skills\codex-windows-fast-patch\SKILL.md" -ErrorAction SilentlyContinue |
                Select-Object -First 1).Directory.FullName
}
if (-not $SkillRoot) {
  throw 'skill root not found; set CODEX_WIN_FAST_PATCH_SKILL_ROOT to the directory that holds this SKILL.md'
}

エージェントがこの SKILL.md を読み込んだディレクトリをすでに把握している場合は、プローブの代わりにそのパスを直接割り当ててください。複数のハーネスにこのスキルがインストールされている場合は、CODEX_WIN_FAST_PATCH_SKILL_ROOT を設定して使用するものを明示的に選んでください。設定しない場合、プローブは最初に見つかったものを使用します。

自己更新の事前確認

スキルのディレクトリは git 作業ツリーなので、更新には git pull を使用します。まず負荷の軽い確認を実行し、変更がなければ残りの手順は省略します。

git -C "$SkillRoot" fetch --quiet origin
git -C "$SkillRoot" rev-list --count 'HEAD..@{u}'

'HEAD..@{u}' はシングルクォートで囲んだままにしてください。PowerShell は引用符で囲まれていない @{u} をハッシュテーブルリテラルとして解析するため、git が実行される前に失敗します。ここでは HEAD..origin/HEAD も同じ意味で、引用符は不要です。

件数が 0 の場合、スキルは最新です。更新を省略し、タスクを開始してください。0 以外の場合は、実際の変更内容を確認してから pull し、その後この SKILL.md を再読み込みしてください。

git -C "$SkillRoot" log --oneline 'HEAD..@{u}'
git -C "$SkillRoot" pull --ff-only

@{u} で上流が設定されていないと報告された場合は、たとえば HEAD..origin/main のように、追跡先の参照を明示的に指定してください。

ルール：

• 更新を理由に修復を中断しないでください。ネットワークが利用できない、GitHub に接続できない、またはプロキシが停止しているために fetch が失敗した場合は、インストール済みのバージョンで作業を続け、更新を省略したことを結論に記載してください。
• ローカルの編集は git によって保持され、黙って破棄されることはありません。pull の前に git -C "$SkillRoot" status --short と git -C "$SkillRoot" diff で確認してください。更新対象ではないファイルへの未コミットの編集は、git pull --ff-only の後もそのまま残ります。更新でも変更されるファイルへの未コミットの編集がある場合、git は pull を拒否し、該当するファイル名を示しますが、編集内容はディスク上に残ります。その場合は git stash、git pull --ff-only、git stash pop の順に実行してください。ローカルの編集と上流の変更が同じ行に触れている場合、stash pop によって競合マーカーが残ることがあります。ローカルコミットがあるとブランチが分岐しているため、--ff-only は拒否されます。git pull --rebase はローカルコミットを更新の上にリベースします。ローカルのヘルパープロファイルと修復ガードは編集内容の中にあるため、pull を強行する目的で git reset --hard や git checkout -- . を絶対に使用しないでください。
• フォークも、リモートが異なるだけです。git -C "$SkillRoot" remote set-url origin <fork-url> を実行すると、更新元が固定されます。追加の設定ファイルは必要ありません。
• ロールバックには git を使用します。git -C "$SkillRoot" log --oneline -10 を実行し、続けて git -C "$SkillRoot" checkout <sha> を実行すると、任意の以前のバージョンに戻せます。
• パッチの適用手順が失敗した場合は、結論を出す前に更新を再確認してください。ヘルパープロファイルが見つからない、パターンが一致しなくなった、または認識されない Desktop ビルドがあるといった状況では、上流ですでに修正されている可能性があります。その場合は、タスク開始時にすでに実行していたとしても、fetch とログの確認を繰り返してください。
• $SkillRoot に .git ディレクトリがない場合、そのコピーはファイルのコピーまたはハーネスプラグインの仕組みでインストールされており、自己更新できません。その旨を報告し、インストール済みのバージョンで作業を続け、今後の更新が可能になるよう git clone で再インストールすることを提案してください。

通常のワークフローで制約、プラグインのゲート、Computer Use の失敗、browser_use の失敗、または Fast Mode の失敗の理由がわからない場合は、スクリプトの編集やパッチの再適用を行う前に references/restriction-debug-cases.md を読んでください。 ブラウザー AX の Decompression failed には、そのリファレンスの AX アセットのケースを使用してください。CUA の子プロキシ変数が見つからない場合は、読み取り専用のプロセスプローブを使用してから、オプトインの -OnlyNodeReplProxyEnv または -OnlyComputerUseSurfaceAndProxyEnv による修復を選択してください。ルートプロセスのプロキシ設定が見つからないというだけでは、パッケージにパッチを適用する根拠にはなりません。 タスクが電話のリモート操作、QR ペアリング、モバイルのセットアップ、分離されたリモート OAuth、リモート操作用 WebSocket、またはペアリング後の API エンドポイントの診断に関する場合は、スクリプトの編集やパッチの再適用を行う前に references/remote-control-debug-cases.md を読んでください。

設定バックアップのルール

$env:USERPROFILE\.codex\config.toml を変更、再生成、または上書きする可能性のある操作を行う前に、タスクごとに現在のファイルのタイムスタンプ付きバックアップを1つ作成してください。これは、エージェントが同梱スクリプトを使う場合、TOMLを手動で記述する場合、別のヘルパーを実行する場合、マーケットプレイスを登録する場合、MCP サーバーを変更する場合、またはComputer Useを修復する場合にも適用されます。

同梱スクリプトは、既存の config.toml がある場合、スクリプトの実行ごとに最初の書き込み前に1回バックアップします。これらのスクリプトを使わない場合は、ファイルに触れる前に明示的にバックアップしてください。

$config = Join-Path $env:USERPROFILE '.codex\config.toml'
if (Test-Path -LiteralPath $config -PathType Leaf) {
  $backupDir = Join-Path (Split-Path -Parent $config) 'backups\config'
  New-Item -ItemType Directory -Force -Path $backupDir | Out-Null
  $backup = Join-Path $backupDir ('config.toml.' + (Get-Date -Format 'yyyyMMdd-HHmmss-fff') + '.manual.bak')
  Copy-Item -LiteralPath $config -Destination $backup -Force
  Write-Host "config.toml backup before overwrite: $backup"
}

既存の設定のバックアップに失敗した場合は、設定を書き込まないでください。共有TOMLライターは、値にアポストロフィまたは制御文字が含まれる場合、基本文字列を使用します。アポストロフィの二重化は有効なTOMLエスケープではありません。tomllib が利用可能な場合は、設定を置き換える前に候補の内容を検証し、修復全体が完了した後にも再度検証してください。Windows PowerShell 5.1では、BOMなしの $OutputEncoding を使っていても、ネイティブの標準入力の先頭にUTF-8 BOMが付くことがあります。有効な内容を誤って拒否しないよう、検証用入力は utf-8-sig でデコードしてください。この転送処理は、BOMなしでファイルを書き込む動作や、不正なTOMLを拒否する動作には影響しません。パーサーが見つからない場合は、ツール上の制約であり、設定が無効である証拠ではありません。

ワークフローの選択

完全なMSIX再パッケージ化の手順を選ぶ前に、現在の問題がDesktopバンドルのゲートによるものか、ローカルのプラグイン／ランタイムの修復によるものかを特定してください。「Chrome／Computer Useを利用できない」という曖昧な報告だけを根拠に、完全な再パッチを実行しないでください。

• Fast Mode のリクエスト／UI の失敗、Desktop のモデルピッカーに新しいモデルが表示されない問題、コンパクトな Power スライダーが従来のピッカーにフォールバックする問題、またはカスタムプロバイダーで Ultra 設定が無効になる問題には、Model Experience ワークフローを使用してください。これらの症状は、同じサービスティア／モデルピッカー領域に関係しています。まず scripts\patch_codex_fast_mode_windows_msix.ps1 -OnlyModelExperience -DryRun を実行してください。Fast リクエストゲート、Fast UI ゲート、モデル表示フィルター、Electron Power スライダーの harborEnabled ゲート、Ultra 設定の永続化を個別にチェックし、壊れている部分だけを1回の MSIX リパックで修復します。Ultra のフォールバックでは通常の ChatGPT アカウント API パスを維持し、ChatGPT のユーザー設定を読み込めない場合に限り、ローカルの show-ultra-in-model-picker-slider 設定を使用します。-OnlyCustomModels は後方互換性のためのエイリアスです。読み取り専用の調査でキャッシュエントリーが存在しないと確認できた場合に限り、不足しているモデルメタデータを models_cache.json にマージしてください。先にキャッシュをバックアップしてください。同じ領域には、公式カタログに gpt-5.6-sol 用の2つ目の ultrafast ティアが追加された一方、カスタム model_catalog_json がそれ以前のものだったため、モデルピッカーに Fast 速度ティアしか表示されない問題も含まれます。これは ASAR の修復ではなく、設定レイヤーのカタログ補完です。references/restriction-debug-cases.md の Ultrafast ティア欠落のケースを参照してください。
• ロケール、プラグイン UI ゲート、browser_use Desktop ゲート、Goal ゲート、ASAR の整合性、設定／UI の利用可否ゲートの修復や、これらの機能と合わせて Model Experience の修復が必要な場合は、フルリパッチのワークフローを使用してください。
• Store の更新後にフルリパッチを行う前に、現在のユーザーと Get-AppxPackage -AllUsers の結果を比較してください。パッチャーは、現在のユーザーまたは SYSTEM-Staged の有効なパッケージのうち最も新しいバージョンと、実行中プロセスの候補を選択します。全ユーザーのクエリが利用できない場合に限り、WindowsApps ディレクトリの候補を使用します。これにより、別のユーザーにのみ登録されているパッケージを選択せずに、より新しい SYSTEM-Staged ビルドが古いユーザーインストール済みパッケージに隠されるのを防げます。続行する前に selected Codex app のログを確認してください。明示的なソースの上書きが必要な場合に限り、-AppPath を使用してください。
• 根拠がローカルのプラグイン／ランタイムの問題を示している場合は、まず Computer Use Only ワークフローを使用してください。該当する症状は、codex plugin list のマーケットプレイスエラー、.agents\plugins\marketplace.json の欠落、openai-bundled プラグインファイルの欠落または不完全な状態、bundled_plugins_marketplace_resolve_failed、バンドルされたプラグインファイルに対する EBUSY、ネイティブパイプが利用できない状態、missing-helper-path、古い Chrome ネイティブメッセージングホストのパス、バンドルされたプラグインキャッシュの不整合、Chrome／ブラウザーキャッシュリンクの不整合、古い SKY_CUA_NATIVE_PIPE 設定、@oai/sky のインポートエラー、setupComputerUseRuntime のインポート失敗です。この種の問題では、後続のチェックでも Desktop ゲートが閉じていると確認されない限り、MSIX のアンインストール／再インストールは必要ありません。
• Store の更新によって、既存の MCP の command が削除済みの %LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node\<old-runtime-id> ディレクトリを指すようになり、動作しなくなった場合は、references/restriction-debug-cases.md の廃止済み CUA Node MCP のケースを使用してください。これは対象を絞った config.toml の修復であり、広範な MSIX リパッチを行う根拠にも、MCP サーバーを追加インストールする許可にもなりません。
• アプリ／ウィンドウの列挙は動作するものの、Windows 10 でスクリーンショットの取得時に SetIsBorderRequired failed／0x80004002 または FrameArrived timed out が発生する場合は、キャッシュパスや Desktop ゲートの問題ではなく、ネイティブ CUA スクリーンショットヘルパーの互換性の問題として扱ってください。キャプチャの失敗に続いて coordinate input geometry is unavailable が発生する場合があります。座標入力を再テストする前に、キャプチャを修復して検証してください。references/win10-computer-use-screenshot-backend.md を読み、読み取り専用のステータスでサポート対象の元のハッシュまたは修正済みハッシュと完全一致した場合に限り、scripts\patch-computer-use-helper-win10.ps1 を使用してください。不明なハッシュは新たに分析する必要があり、変更してはいけません。
• sky.list_windows() は成功するものの、その後の独立した sky.get_window_state() または sky.activate_window() の呼び出しが node_repl exec context not found で失敗する場合は、references/restriction-debug-cases.md の呼び出し間承認のケースを読んでください。文書で指定されている正確な @oai/sky 0.6.2 ヘルパートランスポートでは、永続ヘルパーの承認コールバックが、直前の JavaScript 呼び出しの AsyncLocalStorage ストアを引き継ぐことがあります。install-computer-use-local.ps1 -VerifyOnly はハッシュを検証してリクエストコンテキストのパッチを適用し、-StrictVerifyOnly は検証のみを行います。修復後に現在の JavaScript カーネルをリセットし、その後の独立した呼び出しで実際にキャプチャして修正を確認してください。
• カスタムの model_provider でのみ MCP ツールまたは Computer Use が利用できない場合は、Custom Provider Tool Exposure のトリアージを使用してください。同じマシンと設定で -c model_provider=openai を指定するとすべての MCP ツールが利用できる一方、エージェントが MCP ツール名を0件と報告する症状が該当します。Desktop に手を加える前に、ローカルのログ記録用リバースプロキシを通じて実際のプロバイダーリクエスト本文を取得し、/models のレスポンス形式を確認してください。OpenAI のモデル一覧形式（{"data":[...]}）を返すゲートウェイはカタログのデコードに失敗し（missing field \models`）、supports_search_tool: falseを含むフォールバックのモデルメタデータを強制するため、通信上の形式がnamespaceエントリーであることが示されます。観測された経路では、HTTP 200 でもnamespaceとtool_search のどちらの形式も機能しませんでした。この結果だけでは、ゲートウェイによるフィルタリングか、上流またはモデル側での無視かを区別できません。制御された生リクエストのプローブ、またはゲートウェイの受信／送信の比較によって証明されない限り、どの経路で破棄されたのか（ゲートウェイのフィルターか、モデル側でのこれらの形式の拒否か）は未検証として扱ってください。モデルが口頭で報告したツール情報を根拠にしてはいけません。文書化されている MSIX リパッチと Computer Use のローカル修復は、この種の問題を対象としていません。references/restriction-debug-cases.md` のカスタムプロバイダーチェーンのケースを参照してください。
• cua.getState() は動作するものの、install-computer-use-local.ps1 -StrictVerifyOnly が成功し、Object.keys(cua) に computer／getApp／listApps／listWindows がない場合は、CUA サーフェスロックのケースを使用してください。まずプラグインの構成を調べてください。スクリプトベースの unified-computer-use/scripts/launch.mjs であれば repair-cua-surface-lock.ps1 を使用できますが、26.908 以降のディスクリプターのみのプラグインにはその対象がなく、DryRun の成功後に Desktop の -OnlyComputerUseSurface ASAR ワークフローが必要です。実体化された .mcp.json の編集は一時的な対処です。Desktop の reconcile によって書き換えられる可能性があります。references/restriction-debug-cases.md の両方のサーフェスのケースを参照してください。
• Windows アプリバインディングのケースは、サーフェスを公開した後に、インストール済みの @oai/cua ランタイムが実際に Native app bindings are unavailable for windows. をスローする場合に限り使用してください。記録されている従来のランタイムにはその制約がありましたが、@oai/cua 0.2.5 では Windows の cua.listWindows() と cua.getApp({ windowId }) が利用できます。従来の修復方法を選ぶ前に、インストール済みのランタイムと、そのランタイムに注入されたドキュメントを確認し、新しい会話でネイティブキャプチャを検証してください。
• プロバイダー切り替えツールが config.toml を書き換え、codex mcp list から cua_repl が消えた場合は、設定書き換えのケースを使用してください。バックアップから不足している [plugins."unified-computer-use@openai-bundled"] テーブルを復元し、現在のプロバイダー設定は維持してください。機能キーを復元する前に、実行中の CLI の codex features list で評価してください。CLI 0.155.0-alpha.16.4 では、computer_use は安定版でデフォルト有効、js_repl は削除済みであり、computer_use の明示的なエントリーがなく js_repl = false でもネイティブ CUA は動作します。これらの値だけでは不具合とはいえません。references/restriction-debug-cases.md の過去の設定書き換えのケースを参照してください。
• ユーザーがモバイルとのペアリング／制御を必要としている場合、Connections ページに電話のセットアップカードが表示されない場合、QR ダイアログが読み込み中のままになる場合、リモート制御のセットアップが ChatGPT 認証に移行する場合、Allow ダイアログが失敗する場合、電話に Codex 環境のバージョンが期限切れと表示される場合、または電話から作成したターンが Desktop に届くものの、モデルリクエストが誤った API エンドポイントに送られる場合は、Phone Remote Control ワークフローを使用してください。
• Codex Desktop で新しい会話またはローカルタスクを作成できず、最新の Desktop ログに method=thread/start と missing field inputSchema という語句が記録されている場合は、Missing inputSchema 判定ワークフローを使用してください。これが常に MCP の問題だと決めつけないでください。まず CLI／app-server のスモークテストと Desktop ログを比較し、Desktop が null 以外のアプリ動的ツールを送信しているかを調べてください。問題が疑わしい MCP サーバーに追従する場合は、MCP を切り分けてください。CLI の thread start は成功する一方で Desktop UI が失敗し、抽出した ASAR 内の webview\assets\app-server-dynamic-tools-*.js が名前空間でラップされた dynamicTools オブジェクトを返している場合は、Dynamic Tools Schema ワークフローを使用してください。別の根拠がない限り、この症状に対して Phone Remote Control や Computer Use の修復を実行しないでください。
• ユーザーが model_provider、API アカウント、またはプロバイダー設定を変更した後、公式 Desktop サイドバーから古い会話が消えたものの、ローカルの sessions、archived_sessions、または state_5.sqlite のデータが残っている場合は、Provider History Sync ワークフローを使用してください。会話は再表示されるものの、履歴上の cwd が欠落しているために、開く／続行すると 当前工作目录缺失、current working directory missing、または invalid codex request が発生する場合にも使用してください。このワークフローはデータレイヤーの修復です。サードパーティの復旧ツールは必要なく、ASAR にパッチを適用せず、config.toml も変更してはいけません。
• 最新の Desktop ログで、現在のパッケージのマーケットプレイスよりディスクリプターが少ないことが示される場合、またはユーザーがすでにインストールしたプラグインを not_in_bundled_marketplace_plugin_names が削除している場合は、対象を絞ったバンドル済みマーケットプレイスの修復を使用してください。ディスクリプターが存在することはプラグインが利用可能であることを意味しますが、sites、latex、deep-research、visualize などのオプションのプラグインをインストールまたは有効にする許可にはなりません。これを理由に広範なリパッチや Phone Remote Control ワークフローを開始してはいけません。まず、不足しているディスクリプターの述語全体とプラットフォームのサポートを調べてください。記録されている 26.825.6671.0 の macOS 専用の統合 CUA と、アカウント認証が必要な user-writing の不足は想定どおりです。この境界を維持してください。サポート対象の 26.1007 Code Review と統合 CUA の検出述語には、references/restriction-debug-cases.md の新しいオプションエントリーのケースを使用し、installWhenMissing:false としてください。不明なアカウント述語はサポート対象外です。
• ユーザーが Phone Remote Control と通常の Desktop 機能の両方を同じ修復で求めている場合は、まず Phone Remote Control にパッチを適用し、その後 Fast Mode／browser／Chrome／Computer Use を検証してください。リモート制御の MSIX インストールによって Computer Use または Chrome のネイティブホストの状態が乱れた場合は、ただちに Computer Use Only ワークフローを実行し、-StrictVerifyOnly を再実行してください。
• 新しい resources\codex.exe PE ファイルがあるからといって、app.asar がなくなった、または Computer Use にバイナリパッチが必要だと推測してはいけません。まず現在のパッケージリソースを調べてください。app.asar がまだ存在し、症状がプラグイン／ランタイムのインポートまたはキャッシュの失敗であれば、MSIX やバイナリの変更を検討する前に scripts\install-computer-use-local.ps1 を実行してください。
• Computer Use のみの修復後は、必ず scripts\install-computer-use-local.ps1 -StrictVerifyOnly を実行してください。従来のレイアウトでは client import ok と helper transport ok、ディスクリプターのみのレイアウトでは公式の sky エクスポートをインポートして list_windows を呼び出した後の runtime import ok が成功条件です。認識済みの呼び出し間リクエストコンテキストプロファイルでは、strict verification によって修正済みヘルパートランスポートの正確なハッシュも報告される必要があります。これらのチェックを行っても、後続の JavaScript 呼び出しで実際にスクリーンショットを撮る必要がある点は変わりません。
• ユーザーから依頼がない限り、Phone Remote Control をデフォルトのフルリパッチ経路に含めてはいけません。リモート制御専用の OAuth、ASAR の変更、ネイティブ app-server の置き換えバイナリ、SQLite の登録情報のクリーンアップ、ペアリング後の API エンドポイントの診断が必要になる可能性があるため、オプトインのワークフローです。
• 根拠が混在している場合は、まず影響が最も小さい方法を使用してください。読み取り専用のトリアージを実行し、次にローカルプラグインが原因である証拠があれば scripts\install-computer-use-local.ps1 -VerifyOnly を実行します。必要な場合に限り Codex Desktop を再起動し、ログまたは抽出した ASAR のチェックでゲートが閉じていることが引き続き示された場合にのみ MSIX にエスカレーションしてください。 通常の scripts\repatch-codex-windows.ps1 の事前チェックでは、パッケージに依存する Computer Use のケースを 1 つ認識します。installed app.asar does not preserve external NODE_REPL_TRUSTED_CODE_PATHS across Desktop config regeneration です。つまり、Desktop の設定再生成後も外部の D: マーケットプレイス／キャッシュのルートを維持するには、インストール済みアプリに再パッチを適用する必要があります。このメッセージと完全に一致する場合に限り、ラッパーはフォールバックを記録し、MSIX のドライランまたはインストールへ処理を続けます。これ以外の Computer Use のエラーでは、ワークフローを停止します。インストール後、ラッパーは通常の Computer Use の更新と厳密な検証を実行します。ドライラン中は、現在インストールされているパッケージには意図的にまだパッチが適用されていないため、この認識済みケースに限り、ドライラン後のローカル検証をスキップします。

明示的に OpenAI 以外の認証を使用するカスタムプロバイダーで、Chrome のセッション／タブコマンド、または cua.getState() のブラウザー部分が Codex auth token is unavailable を報告する場合は、references/restriction-debug-cases.md の Chrome カスタムプロバイダーのリクエストヘッダーに関するケースを確認してください。サポート対象のローカルサービスオーバーレイでは、エージェントのリクエストヘッダーを有効のままにします。ログインを偽装したり、プロバイダー／認証ファイルを変更したり、ほかのポリシーを無効化したり、信頼済みブラウザークライアントのバイト列を変更したりすることはありません。ローカルインストーラーは、キャッシュの更新後にハッシュで保護されたオーバーレイを再適用します。修復と厳密な検証の両方で、ブラウザー／Chrome プラグインのコピーと、現在の cua_node ランタイムにある @oai/browser-desktop/service を、それぞれのインストール済みパッケージのソースと照合します。公式ソースのハッシュが不明な場合は、このオーバーレイのみを明示的にスキップし、認証エラーが修復されたとはみなしません。現在のランタイムサービスがない場合、またはサポート対象ソースのファイルが不明、バージョン混在、もしくは不完全な場合は、オーバーレイを書き込む前に失敗します。適用後は、現在の JavaScript カーネルのみをリセットし、実際の Chrome のナビゲーションと入力を検証してください。このエラーに対して Desktop を再インストールする必要はありません。

Desktop を再起動する修復のための外部エグゼキューター

MSIX のデプロイは、アンインストールしてからインストールするのではなく、インプレース更新でなければなりません。3 つすべてのパッチャーがパッケージのリビジョンをインクリメントし、scripts/lib/msix-safe-install.ps1 を使用します。これはデプロイ前に、マニフェスト、発行元、アーキテクチャ、署名、バージョン、パッケージ化されたサービスに必要な管理者権限、インストーラーの起動元を確認します。アクセス許可または同一バージョンに関するエラーが発生した場合は、動作中のアプリを閉じたり削除したりせずに停止しなければなりません。更新失敗への対処として Remove-AppxPackage によるフォールバックを復活させないでください。

Desktop から起動した Start-Process も、Desktop のジョブ／プロセスツリーに属し、Desktop とともに終了することがあります。インストールを開始する前に、外部エグゼキューターの起動元とユーザーセッションを確認してください。windows.service、packagedServices、または localSystemServices を宣言するパッケージでは、昇格されたエグゼキューターが必要です。有効な署名があっても、デプロイ権限があることの証明にはなりません。通常の Windows UAC で同意を取得し、アプリを終了する前に昇格済みトークンを検証してください。実際の起動とランタイムの受け入れ確認に合格するまで、元のプログラムファイルを含む、別途署名されたリカバリーパッケージを、予定している更新より高いリビジョンで保持してください。通常のパッチャーのエントリーポイントは、このリカバリーパッケージを自動作成しません。Invoke-RecoverableMsixInstall は、リカバリーパッケージを準備し、実際の起動検証を提供する外部エグゼキューターで利用できます。references/restriction-debug-cases.md のデプロイ失敗に関するケースを参照してください。

現在の Codex Desktop の会話から、修復の開始、診断、準備、調整を行うことはできます。ただし、Desktop を終了または更新する実際のデプロイは、起動元とユーザーセッションが Desktop のシャットダウン後も維持されることを確認済みの、独立したインストーラーで実行しなければなりません。これはインストーラーの実行期間に関する要件であり、ユーザーが現在の会話から離れる必要があるということではありません。外部の Windows PowerShell または VS Code Codex 拡張機能から開始する方法も有効です。 インストールを実行する前に、どの修正にクライアントの再インストールが必要か、また、ウィンドウが閉じて会話が中断される可能性があることを説明してください。状態をバックアップし、検証済みのアーティファクトとバックアップのパス、インストーラーの PID／ステータスファイルの場所、未完了の受け入れ手順を含む引き継ぎ情報を保存してください。インストール後に Codex を再度開き、元の修復会話で「continue」と送信するようユーザーに伝えてください。再開したら、まず既存のインストーラーと保存済みの結果を確認してください。まだ実行中なら待ち、失敗しているなら原因を調査し、インストールが成功しているなら受け入れ確認とクリーンアップを続けてください。会話が中断されたというだけで、重複したインストーラーを起動したり、完了済みのデプロイを繰り返したりしないでください。インストールエラーが報告された場合や、完了後もアプリが見つからない、または起動できない場合は、通常の待機状態ではありません。

対象となる状態は Desktop Codex のホームで、通常は $env:USERPROFILE\.codex です。Desktop の修復を判断する際に、分離された CLI エントリポイントを使用しないでください。そのラッパーが CODEX_HOME を $env:USERPROFILE\.codex-cli やその他の分離ディレクトリに設定している場合、それは Desktop のプラグイン、マーケットプレイス、MCP、リモートコントロール、ログインの状態ではありません。

VS Code Codex または外部 PowerShell から作業を開始する前に、ユーザーレベルまたはマシンレベルで CODEX_HOME が設定されていないことを確認してください。グローバルな CODEX_HOME を設定しないでください。.codex を .codex-cli にコピーしないでください。また、auth.json、API キー、OAuth トークン、MCP 認証情報、ブラウザープロファイル、ローカルの認証情報ストアを公開したり、コミットしたりしないでください。まず Desktop の状態をバックアップし、読み取り専用のパッケージ／設定／ログの確認を実行してから、該当する -DryRun を実行してください。ドライランで対象が検出され、意図した対象であると検証された後に限り、-Install、完全な repatch-codex-windows.ps1、または対象を絞った *-windows-msix.ps1 -Install -Launch -InstallPrerequisites を使用してください。

再起動後は、以下のバックグラウンド検証を使用してください。実際のネイティブなスクリーンショット／入力テストは、別途許可を得て行う任意の診断です。通常の修復を完了するうえで、これを実施していないことが障害になってはなりません。外部実行環境は、読み取り専用の列挙に公式ランタイムを使用できますが、Desktop の信頼済み Chrome／ブラウザーチャネルの代わりにはなりません。実際に収集した証拠に基づいて、各レイヤーの結果を報告してください。Desktop の外部でネイティブ操作の診断を明示的に依頼された場合は、references/restriction-debug-cases.md の外部実行環境のケースを参照してください。

デスクトップ入力を使わないデフォルトの検証

通常の修復、アップグレード、「すべての機能を検証」する依頼では、デフォルトでバックグラウンドチェックを使用します。修復が機能したことを示す目的だけで、電卓、メモ帳、タスク マネージャー、その他のテスト用アプリを開いたり、ネイティブウィンドウをアクティブ化、復元、移動、または閉じたり、クリック、スクロール、ドラッグ、キーボード入力を送ったりしないでください。同じように介入的なテストを、別のアプリや外部プロセスの入力ドライバーで代用しないでください。

• scripts\install-computer-use-local.ps1 -StrictVerifyOnly -VerifyAllBundledPluginsAvailable を実行します。アプリを選択したり入力を注入したりせずに、現在のパッケージ／キャッシュ／ランタイムの契約、ブラウザー AX アセット、ネイティブホストの構成、信頼済みパス、および実際のヘルパーの list_windows レスポンスを確認します。
• 新しい Desktop CUA サーフェスの確認が関係する場合は、文書化された API を使用して、利用可能なメンバーの確認とウィンドウ／アプリの列挙だけを行います。無関係なウィンドウタイトルを公開せずに、件数と API の利用可否を報告します。列挙に成功すればトランスポートが利用可能であることを確認できます。ウィンドウ一覧が空であることだけでは、失敗の証明にはなりません。
• 必要に応じて、パッケージの整合性、プラグインの検出、サンドボックス、Fast のリクエストワイヤーチェックを続けます。依頼されたブラウザチェックには、Browser Use 経由の一時的なバックグラウンドタブを使用できます。ブラウザー入力の成功は、Windows ネイティブ入力の成功を示すものではありません。
• ネイティブ操作を実際にテストしていない場合は、「ランタイム／トランスポートを検証済み。ネイティブのスクリーンショット／入力は未実施」として結果を報告します。この制限をより広い成功の主張に変えるため、インタラクティブテストへ自動的に移行しないでください。

スクリーンショットまたは入力の不具合を再現する必要がある場合は、まず対象のウィンドウ、操作、想定されるフォーカスの変化を説明し、その診断について明示的な許可を得てください。同じ操作を実行する明示的な依頼がすでにある場合は、再度確認する必要はありません。利用可能であれば、使い捨ての VM／テスト用デスクトップ、またはユーザーが選んだアイドル時間を優先してください。非表示または画面外のウィンドウなら Windows の入力注入による妨げにならないと決めつけないでください。このスキルと参照資料に記載されている任意のライブチェックにも、この制限が適用されます。

ユーザーが Escape キーを押す、Computer Use を停止する、テストウィンドウを閉じる、または対象で作業を再開した場合は、インタラクティブテストを停止し、最後に完了した手順を報告します。テスト用アプリを自動的に再度開いたり、入力を再試行したり、別の制御方法に切り替えたりしないでください。デスクトップへの入力を追加で行わなくても、バックグラウンドチェックと修復レポートは完了できます。

Windows 11 ホストから調査する Windows 10 のスクリーンショット問題については、references/win10-validation-on-win11.md に従ってください。scripts\diagnose-win10-helper-capture.ps1 はデフォルトで読み取り専用です。-BuildTargetOnly は起動せずに専用ターゲットをコンパイルします。明示的に許可された -RunCapture は、Windows 10 ゲスト／テストコンソール、分離されたヘルパーのコピー、および使い捨ての Codex ホームを使用します。-TestInput は、そのターゲット内に限定したクリック／テキスト入力を個別に有効にします。このスクリプトは Windows 11／Server でのキャプチャを拒否し、アクティブなヘルパーにパッチをインストールすることはありません。コンパイル、候補のハッシュ、診断ガードテストだけでは、Windows 10 のキャプチャが受け入れられることを確認できません。

デフォルトのワークフロー

1. タスクによって config.toml、スキル、マーケットプレイス、または MCP サーバーの設定が変更される可能性がある場合は、最初に状態のスナップショットを作成します。

powershell -NoProfile -ExecutionPolicy Bypass -File "$SkillRoot\scripts\manage-codex-backups.ps1" -Action Backup

2. 現在のユーザーと全ユーザーのパッケージ状態を確認し、より新しい SYSTEM-Staged Store ビルドが見えるようにします。

Get-AppxPackage -Name OpenAI.Codex | Select-Object Name,PackageFullName,Version,SignatureKind,InstallLocation
Get-AppxPackage -Name OpenAI.Codex -AllUsers |
  Select-Object Name,PackageFullName,Version,SignatureKind,InstallLocation,PackageUserInformation

MSIX パッチャーは、現在のユーザーに対するクエリで古いインストール済みビルドが返された場合でも、app レイアウトが完全な候補のうち最もバージョンの高いものを自動的に選択します。インストール前に、ログの selected Codex app と source package の行を確認してください。明示的に指定した -AppPath は引き続き優先されます。

3. パッケージを再インストールする前に、読み取り専用の機能トリアージを実行します。特に Chrome／Computer Use について、判断の根拠となる情報を取得します。

codex plugin list
powershell -NoProfile -ExecutionPolicy Bypass -File "$SkillRoot\scripts\install-computer-use-local.ps1" -StrictVerifyOnly

-StrictVerifyOnly が、マーケットプレイスマニフェストの欠落、プラグインファイルの欠落、古い latest リンク、古い Chrome ネイティブメッセージングマニフェストパス、allowed_origins、レジストリ値、または extension-host-config.json のランタイムパス、ヘルパーパスの欠落、あるいは @oai/sky のインポート／ランタイムの問題で失敗する場合は、まず Computer Use Only の修復を実行してください：

powershell -NoProfile -ExecutionPolicy Bypass -File "$SkillRoot\scripts\install-computer-use-local.ps1" -VerifyOnly

このローカル修復は、構成、プラグインキャッシュ、Chrome ネイティブホストのパスとオリジン、ユーザー環境、およびヘルパーのランタイムファイルを更新する場合がありますが、Codex MSIX パッケージをアンインストールまたは再インストールすることはありません。これは、インストール済みパッケージとハッシュが一致するユーザーローカルの Codex CLI と、一致する現在の cua_node の node.exe / node_repl.exe パスを使用して、現在の Chrome プラグインの公式 scripts\installManifest.mjs を呼び出します。この公式インストーラーは、外側のネイティブホストマニフェスト、レジストリ値、および必要な extension-host-config.json を書き込みます。また、この修復は、現在のプラグインの NUL 区切りの SHA-256 識別契約を使用して、現在の schema-2 app-server エントリを %LOCALAPPDATA%\OpenAI\Codex\chrome-native-hosts-v2.json と $env:USERPROFILE\.codex\chrome-native-hosts-v2.json の両方に同期します。厳格な検証には、scripts\extension-ids.json からの正確な現在のオリジンセット、安定した現行バージョンの Chrome キャッシュ、ホスト構成に存在する現在のランタイムパス、および両方の v2 状態ファイルにおける有効な現在のエントリが必要です。26.814 形式のビルドでは、そのエントリに同じ安定したキャッシュ内の browserClientPath と browserServicePath の両方を含める必要があります。サービスパスを省略すると、バイトチェックは通過しますが、信頼された RPC 依存関係ゲートで失敗します。安定したキャッシュが CODEX_HOME の外側のジャンクションを経由して解決される場合、修復はその物理的なマーケットプレイス／キャッシュルートをユーザーレベルの NODE_REPL_TRUSTED_CODE_PATHS にも書き込みます。Desktop が Node REPL 構成を再生成する際にその親環境値を追加するには、完全な MSIX パッチが依然として必要です。厳格な検証には、この外部ルートレイアウトのために、インストール済み ASAR 内の CODEX_NODE_REPL_TRUSTED_PATHS_V1 が必要です。

修復は、インストール済みパッケージの plugins\chrome\scripts\browser-client.mjs のバイト列を正確に保持する必要があります。以前の Node REPL ビルドでは、インポートされた browser-client の SHA-256 がインストール済み app.asar に埋め込まれた信頼リストと一致する場合にのみ、特権的なブラウザ機能が公開されます。node:process のインポートやプロセスシムを書き換えるとハッシュが変わり、Chrome の検出前に Browser use requires privileged node_repl capabilities が発生します。Codex Desktop 26.814 は代わりに公式ネイティブホスト構成を通じて browserClientPath を配信し、クライアントハッシュを app.asar に ASCII として埋め込まなくなりました。通常の修復は、パッケージ化されたバイト列を安定したマーケットプレイスとバージョン付きキャッシュの両方に復元します。厳格な検証には、両方のコピーがパッケージ化された SHA-256 と一致すること、そしてその後、レガシー ASAR ハッシュまたは完全なネイティブホストパス契約のいずれかが必要です。不明または部分的な形状はサポート対象外のままです。

4. 完全な MSIX 再パックを選択する前に、これがバンドルされたマーケットプレイスのファストパスであるかどうかを確認してください。パッケージの .agents\plugins\marketplace.json の名前を Desktop の reconcile ログと比較します。記述子が欠落している場合、または not_in_bundled_marketplace_plugin_names がユーザーがすでにインストールしていたプラグインを削除する場合は、大容量のローカルドライブ上で対象を絞ったバンドルマーケットプレイスパッチのみを実行してください：

powershell -NoProfile -ExecutionPolicy Bypass -File "$SkillRoot\scripts\patch_codex_fast_mode_windows_msix.ps1" -OnlyBundledMarketplaceCopy -DryRun -OutputRoot "<large-local-build-root>"
powershell -NoProfile -ExecutionPolicy Bypass -File "$SkillRoot\scripts\patch_codex_fast_mode_windows_msix.ps1" -OnlyBundledMarketplaceCopy -Install -Launch -InstallPrerequisites -CleanupAfter -CleanupWindowsSdkAfterInstall -OutputRoot "<large-local-build-root>"

再起動後、scripts\install-computer-use-local.ps1 -VerifyOnly と scripts\install-computer-use-local.ps1 -StrictVerifyOnly -VerifyAllBundledPluginsAvailable を実行します。ローカル修復は、無関係な各オプションプラグインのインストール済み／有効化状態を保持し、そのプラグインがすでにインストールされていた場合にのみ、オプションのキャッシュを更新します。可用性チェックでは、すべての現在の記述子の名前とバージョンがインストール済みパッケージと一致し、plugin add を呼び出さずに CLI のインストール済みまたは利用可能な JSON にそのバージョンで現れる必要があります。 5. 証拠から、パッケージによって制御される Desktop コードが原因だと判断できる場合に限り、MSIX による修復へ進みます。対象となるのは、Fast Mode のリクエスト／UI のゲート、ロケールのゲート、Goal／プラグイン UI のゲート、reason=statsig-disabled によって利用できない browser_use、ローカルで修復した後も設定／UI の利用可否ゲートによって無効になっている Computer Use／Any App、ASAR の整合性エラー、ローカルで修復した後も信頼済み RPC 依存関係ゲートに物理ターゲットを拒否される安定した Browser キャッシュジャンクション、または Phone Remote Control のパッケージパッチです。ジャンクションの場合は、パッチャーの完全な Node REPL trusted-paths patch result を確認し、Desktop を再起動して、再生成された設定に解決済みの外部ルートが保持されていることを確認してください。それ以外の場合、プラグインが利用できないという理由だけで完全な再パッチを実行しないでください。

MSIX による修復が妥当な場合は、Codex のアップグレード後にまずドライランを実行してください。

powershell -NoProfile -ExecutionPolicy Bypass -File "$SkillRoot\scripts\repatch-codex-windows.ps1" -DryRun

6. ドライランですべてのパッチ対象が見つかった場合は、完全な再パッチを実行してください。

powershell -NoProfile -ExecutionPolicy Bypass -File "$SkillRoot\scripts\repatch-codex-windows.ps1"

ラッパーは、次のデフォルト設定でバンドルされたパッチスクリプト scripts\patch_codex_fast_mode_windows_msix.ps1 を呼び出します。

• -InstallPrerequisites
• -Install
• -Launch
• -CleanupWindowsSdkAfterInstall
• -CleanupAfter
• -VerifyFastModeRequest また、ローカルマーケットプレイス設定を $env:USERPROFILE\.codex\marketplaces\openai-curated-local に検証して書き込みます。これには source_type = "local" と正確な source パスが含まれます。 また、インストール済みの openai-bundled マーケットプレイスを現在の Codex パッケージから安定したローカルルートに同期し、ローカルの computer-use@openai-bundled 互換プラグインをオーバーレイし、そのマーケットプレイスを設定に書き込み、ユーザーがアクセス可能な Codex CLI を通じて browser@openai-bundled を登録します。-VerifyAllBundledPluginsAvailable を渡すと、インストール済みパッケージが現在提供しているすべての完全な記述子（deep-research や visualize などバージョン依存のプラグインを含む）に対して可用性アサーションを追加します。アサーション自体は plugin list --available --json を使用します。ネットワークからダウンロードしたり、plugin add を呼び出したり、無関係なオプションのプラグイン状態を変更したりはしません。周囲のラッパーは、要求された修復または DryRun の動作を引き続き実行します。.codex\.tmp がジャンクションの場合、安定したルートはジャンクションターゲットの隣に作成されるため、既存の非システムドライブのレイアウトは C: 上に残りません。それ以外の場合は .codex\marketplaces\openai-bundled-local を使用します。また、安定した browser / chrome プラグインのキャッシュコピーを修復して、それらの latest ジャンクションが可変の .tmp マーケットプレイスミラーを指さないようにし、現在のユーザーに対して CODEX_ELECTRON_ENABLE_WINDOWS_COMPUTER_USE=1 を有効にして、再起動後にデスクトップアプリが Windows Computer Use を公開できるようにします。 リクエストパスと設定 UI パスの両方で Fast Mode にパッチを適用します。リクエストパッチは ChatGPT 専用の分岐を削除しつつ、ホスト/モデルの機能要件を引き続き読み取ります。UI パッチは、サービスティア設定における対応する ChatGPT 専用の可用性チェックを削除します。 また、設定されたカスタムモデル ID をデスクトップのモデル可視性フィルターに強制的に通します。デフォルトではこれらは gpt-6-astra、gpt-6-sol、gpt-5.6-sol、gpt-5.6-terra、gpt-5.6-luna です。このパッチは、現在のビルドにすでに存在するカタログエントリを非表示解除するだけであり、新しいエントリを作成することは決してありません。アクティブなカタログに含まれていないスラッグは、バンドルに何度パッチを再適用してもピッカーに表示されないため、モデルの欠落をパッチの失敗と解釈する前に、そのエントリが存在することを確認してください。CLI の組み込みカタログは codex.exe に埋め込まれており、まだ展開されていないモデルを "visibility": "hide" 付きで同梱することがあります。これはこのパッチが処理する形態の 1 つです。ユーザーの model_catalog_json はその組み込みカタログを拡張するのではなく置き換えるため、新しいエントリ自体をそこに含める必要があります。プロバイダーが gpt-6-sol のような新しいスラッグを通知する場合、アクティブなカタログをバックアップし、存在すればそれに一致する完全な組み込みエントリをインポートしてください。無関係なモデル設定を保持し、カタログ修復を主張する前に model/list を検証してください。プロバイダーに確認せずに別のモデルの機能を推測したり、組み込みモデルをプロバイダーがサポートしていると通知したりしないでください。コンパクトな Power スライダーを含むビルドでは、このパッチは Electron 固有の harborEnabled ゲートも開き、一致するモデルと推論の組み合わせが、従来のモデル/エフォート/スピードのみのメニューではなくそのスライダーを使用するようにします。 Ultra スライダー設定が ChatGPT アカウントのユーザー設定のみを読み取るビルドでは、サードパーティプロバイダー向けのローカルフォールバックを追加します。その後トグルは show-ultra-in-model-picker-slider をローカルで読み書きし、再起動後も維持され、実際のモデルピッカーが使用するのと同じ Ultra 包含値を供給します。通常の ChatGPT 認証ユーザーは公式のアカウント設定パスを保持します。 出荷される webview バンドルで enable_i18n が無効になっているときに、再起動後にデスクトップ UI を英語に強制的に戻す可能性があるロケール i18n ゲートにパッチを適用します。 webview アセットとメイン Electron の機能送受信パスの両方で Chrome/browser_use ゲートにパッチを適用し、アプリ内ブラウザ、ブラウザペイン、外部ブラウザの可用性をカバーします。これはローカルのデスクトップゲートを解放するだけであり、Chrome 拡張機能とネイティブメッセージングのファイルは依然として存在する必要があり、別途検証する必要があります。 また、computer_use 機能と Statsig ゲート 1506311413 の背後で Windows Computer Use を非表示または無効にするデスクトップ webview ゲートにパッチを適用し、features.computer_use = true を $env:USERPROFILE\.codex\config.toml に、[features] テーブルの残りの部分を置き換えずに書き込みます。 また、[windows] sandbox = "unelevated" を $env:USERPROFILE\.codex\config.toml に書き込みます。Windows では、これにより spawn setup refresh / OS エラー 740 で失敗し Computer Use の起動を壊す可能性がある、昇格されたサンドボックスセットアップのリフレッシュパスを回避します。 また、ローカルルートにレガシーのルート marketplace.json しかない場合に、ローカルマーケットプレイスのマニフェストレイアウトを修復します。現在の Codex CLI は .agents\plugins\marketplace.json を期待しており、そのファイルが欠落していると、設定されたすべてのマーケットプレイスに対して codex plugin list が失敗する可能性があります。 デフォルトでは、バンドルされたカスタム model_instructions_file プロンプトをインストールしません。ユーザーがそのオプション設定を明示的に要求した場合にのみインストールしてください。 既存の config.toml へのバンドルスクリプトによる書き込みは、そのスクリプト実行に対して最初に .codex\backups\config\ の下にタイムスタンプ付きのバックアップを 1 つ作成します。

Phone Remote Control

電話のリモートコントロールを修復する前に、references/remote-control-debug-cases.md を読んでください。以下の境界を明確に保ってください。

• リモートコントロールのペアリング／制御のトランスポートでは、正規の接続先として https://chatgpt.com/backend-api/wham/remote/control/... を呼び出す場合があります。このトランスポートをサードパーティのモデル API エンドポイントに書き換えないでください。
• 電話のペアリングが機能した後、実際のモデルサンプリングリクエストの URL を確認してください。誤ったモデル API エンドポイントに接続している場合は、リモートコントロールのペアリング実装ではなく、ペアリング後の設定診断として扱ってください。
• リモートコントロールの OAuth は分離されています。.codex\remote-control-oauth.json と .codex\remote.json を使用し、リモートコントロールのベアラー注入経路には .codex\auth.json を決して使用しないでください。
• ユーザーがシステムドライブを使用しないよう指定した場合は、別のビルドルートが必須です。指定された大容量のローカルドライブで -WorkRoot／-OutputRoot を渡し、Cargo、Rustup、一時ファイル、target、MSIX、ソースチェックアウトをそのルート配下に置いてください。ワークフローにドライブ文字をハードコードしないでください。

Settings -> Connections -> Control this computer が表示されているものの、デバイスリストに ChatGPT への再サインインを求めるメッセージが表示される場合は、MSIX を再度パッチする前に、通常のリモートコントロールベアラーを確認してください。

python "$SkillRoot\scripts\refresh-remote-control-auth.py" --verify-only

この確認で remote_json_disabled、access_token_expired、endpoint_http_error、HTTP 401／403、または refresh_token_reused などのトークン更新に関する診断が報告された場合は、同じスクリプトで .codex\remote.json のみを再生成してください。このスクリプトは公式の Codex OAuth クライアントを使用し、openid profile email offline_access api.connectors.read api.connectors.invoke を要求して、古い remote.json を .codex\backups\remote-control-auth にバックアップします。既定のプロキシは http://127.0.0.1:10808 です。また、.codex\auth.json や config.toml に書き込んではいけません。

remote.json の検証に成功しているにもかかわらず、Add をクリックするか Control this computer を開くと、新しい会話／メインチャットページに戻る場合は、$env:USERPROFILE\.codex\remote-control-flow.log とエンドポイントへの直接リクエスト結果を調べ、期限切れの remote-control-oauth.json 登録トークンが通常のベアラーを覆い隠していないか確認してください。ASAR パッチャーは、分離されたベアラーを返す前に期限切れの JWT を除外し、パッチ適用済み ASAR に remote_control_auth_token_expired_skipped があることを確認してください。.codex\remote-control-oauth.json をむやみに削除しないでください。新しいステップアップ／登録フロー用に保持し、有効な .codex\remote.json で読み取り／MFA エンドポイントを利用できるようにしてください。

Allow ダイアログが失敗し、最新のネイティブアプリサーバーログに remote control requires ChatGPT authentication; API key auth is not supported と表示されている場合は、ASAR のパッチ適用と .codex\remote.json の更新だけでは不十分です。Codex Rust ソースと参照用ネイティブパッチを使用して、パッチ適用済みのネイティブ app\resources\codex.exe をビルドしてください。大容量の非システム作業ルートが指定されている場合は、それを使用してください。

powershell -NoProfile -ExecutionPolicy Bypass -File "$SkillRoot\scripts\build-remote-control-native-replacement.ps1" -WorkRoot "<large-local-build-root>\native-remote"

ネイティブ置換後に、電話に Codex 環境の有効期限切れが表示される場合は、ビルドする前に、インストールされている元のネイティブバージョンを確認してください。完全に一致する対応済みの Desktop／ネイティブ／ソースタグの組み合わせのみを使用してください。たとえば、Desktop 26.715.2305.0 には codex-cli 0.145.0-alpha.18 が同梱され、Desktop 26.707.3748.0 には codex-cli 0.144.0-alpha.4 が同梱されています。

powershell -NoProfile -ExecutionPolicy Bypass -File "$SkillRoot\scripts\build-remote-control-native-replacement.ps1" -WorkRoot "D:\CodexData\rc145" -CodexSourceRef "rust-v0.145.0-alpha.18" -AppServerVersion "0.145.0-alpha.18"
powershell -NoProfile -ExecutionPolicy Bypass -File "$SkillRoot\scripts\build-remote-control-native-replacement.ps1" -WorkRoot "D:\CodexWork\phone-remote-26.707\native-remote-0.144.0-alpha.4" -CodexSourceRef "rust-v0.144.0-alpha.4" -AppServerVersion "0.144.0-alpha.4"

ビルドヘルパーは、クローン、Cargo キャッシュ、Rustup キャッシュ、一時ディレクトリ、ターゲットディレクトリ、およびブートストラップされた Windows SDK パッケージをすべて -WorkRoot の下に保持します。-CodexSourceRef と -AppServerVersion の両方を省略すると、インストール済みの WindowsApps にある app\resources\codex.exe を WorkRoot\tmp にコピーし、そのコピーに対してのみ --version を実行して、同梱のバージョン対応表から選択します。WindowsApps 内のバイナリをそのまま実行することはありません。Desktop 26.715.2305.0 は rust-v0.145.0-alpha.18、references\remote-control-native-replacement-0.145.0-alpha.18.patch、およびワークスペースのバージョン 0.145.0-alpha.18 に対応します。Desktop 26.707.3748.0 は rust-v0.144.0-alpha.4、references\remote-control-native-replacement.patch、およびワークスペースのバージョン 0.144.0-alpha.4 に対応します。過去のバージョン rust-v0.142.4 では、一致するパラメーターを指定すると references\remote-control-native-replacement-0.142.4.patch が選択されます。このパッチはクリーンなパッチ適用検証に合格していますが、新しい対応バージョンと同等のエンドツーエンドのネイティブコンパイル検証はまだ完了していません。それ以外のソースバージョンでは、一致する明示的なバージョンパラメーターと、検証済みの -PatchPathOverride が必要です。Windows MSIX の置き換えには、GNU ツールチェーンの出力を使用しないでください。MSVC ターゲットを使用してください。

MSVC が存在しても kernel32.lib がない場合、ヘルパーはまず、一致する x64 版の kernel32.lib、ucrt.lib、およびヘッダーを含む、既存の一貫した Windows SDK のルート／バージョンを検索します。インストール済みの SDK バージョンを個別に検出して混在させることはありません。使用可能な SDK がない場合に限り、Microsoft.Windows.SDK.CPP と Microsoft.Windows.SDK.CPP.x64 のバージョン 10.0.26100.4188 を <WorkRoot>\cache\windows-sdk-cpp にダウンロードします。ダウンロードには .partial ファイルを使用し、アーカイブと想定されるペイロードを検証してからキャッシュを置き換えます。破損したキャッシュ済みパッケージは削除して再ダウンロードします。Windows PowerShell 5.1 では、検証済みの tar.exe を使って NuGet パッケージを展開してください。深くネストした _rels\.rels ツリーのクリーンアップ中に Expand-Archive が失敗することがあります。2 つのパッケージは分割されたレイアウトを使用するため、従来のインストール済み Kits ツリーが 1 つあることを必須とせず、一致する NuGet ルートにある c\um\x64\kernel32.lib、c\ucrt\x64\ucrt.lib、c\Include\<version>\um\Windows.h、および任意の c\bin\<version>\x64\rc.exe を受け入れてください。ダウンロードでは、既存の HTTPS_PROXY／HTTP_PROXY が使用されます。どちらも設定されていない場合、ポートがリッスン中のときに限り、ヘルパーは http://127.0.0.1:10808 を使用します。それ以外の場合は直接ダウンロードします。

-WorkRoot はシステムドライブ以外にするだけでなく、短くしてください。D ドライブ上でも深くネストしたルートでは、Cargo が Git 依存関係をチェックアウトするときに path too long エラーで失敗することがあります。検証済みの 0.145.0-alpha.18 ビルドは D:\CodexData\rc145 の下で成功しました。中断またはタイムアウトした外部実行を再試行する場合は、まず子 PowerShell プロセスが終了したことを確認し、一意の WorkRoot／OutputRoot を使用してください。タイムアウトした親プロセスが、前回のルートをクリーンアップしている子プロセスを残している場合があります。

まずドライランを実行してください。失敗したパッチの成果物を調べる必要がない限り、-KeepWorkDir を指定しないでください。ドライランが成功した場合、生成されたパッケージと ASAR の展開出力はクリーンアップされます。

powershell -NoProfile -ExecutionPolicy Bypass -File "$SkillRoot\scripts\patch-remote-control-windows-msix.ps1" -DryRun

マシンにより大きな一時ビルド領域が必要な場合は、明示的に指定してください。

powershell -NoProfile -ExecutionPolicy Bypass -File "$SkillRoot\scripts\patch-remote-control-windows-msix.ps1" -DryRun -OutputRoot "<large-local-build-root>"

パッチを適用したネイティブの app\resources\codex.exe を Codex Rust ソースからビルドした場合は、明示的に指定してください。

powershell -NoProfile -ExecutionPolicy Bypass -File "$SkillRoot\scripts\patch-remote-control-windows-msix.ps1" -DryRun -ReplacementResourceCodexExe "<path-to-built-codex.exe>"

ドライランのマーカーが合格した後に限り、インストールして再起動してください。

powershell -NoProfile -ExecutionPolicy Bypass -File "$SkillRoot\scripts\patch-remote-control-windows-msix.ps1" -Install -Launch -InstallPrerequisites -ReplacementResourceCodexExe "<path-to-built-codex.exe>"

makeappx.exe／signtool.exe がない場合、インストール処理では Windows SDK BuildTools を NuGet から %TEMP% ではなく -OutputRoot\.remote-control-temp の下にダウンロードします。このダウンロードにローカルプロキシをハードコードしないでください。まず既定の直接接続／環境変数で指定されたプロキシ経由の方法を使用してください。そのプロキシがリッスン中であると確認できている場合に限り、-BuildToolsProxy "http://127.0.0.1:10808" を指定するか、CODEX_WINDOWS_SDK_BUILDTOOLS_PROXY を設定してください。プロキシ URI と認証情報が出力されることはありません。curl download failed with exit code 7 は通常、選択されたプロキシエンドポイントが接続を拒否したことを意味します。 外部の PowerShell プロセスから破壊的なインストールコマンドを実行し、子プロセスの実際の終了コードを判定します。Windows PowerShell 5.1 では、$ErrorActionPreference = 'Stop' のときに *>&1 を Tee-Object にパイプしないでください。stderr に書き込まれた npm の警告が終了を伴う RemoteException レコードになることがあります。子プロセスの stdout と stderr を同じファイルにリダイレクトしないでください。Start-Process powershell.exe -Wait -PassThru -RedirectStandardOutput <stdout-file> -RedirectStandardError <stderr-file> を使用し、ExitCode を確認してから、プロセスの終了後に 2 つのログをマージまたは要約します。

アンインストール/署名の後にインストール試行が中断され、Get-AppxPackage -Name OpenAI.Codex がパッケージを返さない場合は、まず再ビルドしないでください。選択した -OutputRoot に既存のパッチ済み MSIX がある場合は、それをインストールします:

Add-AppxPackage -Path "<large-local-build-root>\OpenAI.Codex_<version>_remote-control-patched.msix" -ForceApplicationShutdown -Verbose

クリーンアップポリシー: 成功したリモートコントロールスクリプトの実行では、生成された MSIX ステージングディレクトリ、ASAR 抽出物、スクリプトローカルの npx キャッシュ、インストールされたパッチ済み .msix 成果物、および一時的な Windows SDK BuildTools を削除します。ユーザーが修復のみを求めており、再利用可能なビルド成果物の保持を求めていない場合は、ネイティブソースのチェックアウト、Cargo/Rustup キャッシュ、target ディレクトリ、一時ディレクトリ、およびこの修復のためだけに作成された生成済みパッチ/MSIX ファイルも削除します。インストールされたパッチ済みパッケージ、.codex\remote.json、.codex\remote-control-oauth.json、auth/config/sqlite の状態、ログ、および明示的なバックアップは保持します。

Phone Remote Control をインストールした後、通常の機能がリモートコントロールの再パッケージ化後も維持されていることを確認します。少なくとも、リモートコントロールとブラウザのローカルパッチ適用済み可用性についてライブ ASAR マーカーを確認し、置換バイナリを使用した場合はライブネイティブマーカーを確認し、scripts\install-computer-use-local.ps1 -StrictVerifyOnly を実行し、codex plugin list を実行し、Windows サンドボックススモークテストを実行し、Chrome ネイティブメッセージングマニフェストが安定したバージョン付きキャッシュパス、またはバージョン付きキャッシュディレクトリに解決される chrome\latest ジャンクションを指しており、.tmp やその他の可変のマーケットプレイスミラーを決して指していないことを確認します。厳格チェックが古い Chrome ネイティブホストマニフェストまたは欠落しているバンドルキャッシュを報告した場合は、scripts\install-computer-use-local.ps1 -VerifyOnly を実行し、その後 -StrictVerifyOnly を再実行します。

共有ログデータベースを読み取る際は、実行中の WindowsApps アプリサーバープロセスと古い拡張機能のアプリサーバープロセスを区別してください。古い Antigravity/VS Code 拡張機能の codex.exe は、WindowsApps パッケージが修正された後も API key auth is not supported をログに記録し続けることがあります。修復が失敗したと判断する前に、プロセスパスまたは pid でフィルタリングしてください。

スマートフォンで作成されたターンがデスクトップに到達するものの、誤ったモデル API エンドポイントに対して失敗する場合は、何も変更する前に、具体的なリクエスト URL、config.toml、および影響を受けるスレッド/セッションメタデータを検査してください。これはペアリング後の構成診断として扱い、リモートコントロールのペアリングの一部としては扱わないでください。会話履歴を保持し、URL を変更するためだけに model_provider の id を変更しないでください。

Dynamic Tools Schema

missing field inputSchema の Desktop dynamicTools バリアントには、この対象を絞った MSIX/ASAR パスのみを使用してください。必要な証拠：

• 最新の Desktop ログに、missing field inputSchema を含む method=thread/start が記録されている。
• CLI／app-server のスモークテストでは、Desktop アプリの dynamic tools を送信しない場合にスレッドを開始できる。例：codex debug app-server send-message-v2 "只输出 OK"、または dynamicTools:null を指定する同等の thread/start パス。
• Desktop ログまたは抽出したバンドルから、MCP サーバーの起動後ではなく、Desktop アプリの dynamic tools が組み立てられた後に失敗していることが分かる。
• 抽出した webview\assets\app-server-dynamic-tools-*.js が、古い名前空間ラッパー形式 [{type:\namespace`, name, description, tools:[...]}]` を返す。

これらの条件に該当する場合は、Desktop アセットを修正し、namespace、name、description、inputSchema、および任意の deferLoading を含むフラットな DynamicToolSpec[] エントリを返すようにしてください。このバリアントでは、別個の MCP 固有の障害が残っていない限り、MCP サーバーを無効にしないでください。

まずドライランを実行してください。システムドライブの空き容量が少ない場合は、大容量のローカルドライブに -OutputRoot を指定してください：

powershell -NoProfile -ExecutionPolicy Bypass -File "$SkillRoot\scripts\patch-dynamic-tools-windows-msix.ps1" -DryRun -OutputRoot "<large-local-build-root>"

ドライランが成功したら、インストールして再起動してください：

powershell -NoProfile -ExecutionPolicy Bypass -File "$SkillRoot\scripts\patch-dynamic-tools-windows-msix.ps1" -Install -Launch -InstallPrerequisites -OutputRoot "<large-local-build-root>"

インストール後、実際の Desktop UI または最新の Desktop ログで確認してください。Desktop の dynamicTools を迂回する可能性があるため、CLI のみのスモークテストでは不十分です。最新の thread/start エントリで missing field inputSchema が報告されていないことを確認し、Computer Use、Chrome、またはブラウザーの使用が対象の場合は、scripts\install-computer-use-local.ps1 -StrictVerifyOnly と codex plugin list を実行してください。

クリーンアップポリシー：dynamic-tools スクリプトの実行に成功すると、生成された MSIX ステージングディレクトリ、ASAR の展開先、スクリプトローカルの npx キャッシュ、-OutputRoot 配下の一時 SDK キャッシュ、およびインストールされた修正済み .msix アーティファクトが削除されます。-KeepWorkDir は、実行が失敗した場合、または現在デバッグ中の場合に限り使用してください。

Provider History Sync

model_provider、API アカウント、またはプロバイダー設定の切り替え後に Codex Desktop のローカル会話が表示されなくなった一方で、実際のローカル履歴ファイルが残っている場合は、この対象を絞ったワークフローを使用してください。通常、根本原因は Codex がアクティブなプロバイダーバケットに基づいて公式サイドバーをフィルタリングしていることです。古いスレッドの行とロールアウトのメタデータは、以前のプロバイダーの下に残っています。

復元された会話が公式サイドバーに表示されるものの、Desktop で作業ディレクトリが見つからないと報告され、続行できないという第 2 段階の障害にも、このワークフローを使用してください。この場合、プロバイダーバケットはすでに正しい可能性がありますが、永続的な信頼できるデータが、現在は存在しない古い session_meta.payload.cwd ディレクトリを指していることがあります。

このワークフローは、検証済みのローカル履歴メカニズムを直接使用し、外部の復元ツールをインストールまたは必要としません。config.toml から現在のプロバイダーを読み取り、ローカル履歴ストアのプロバイダーメタデータを整合させます：

• sessions および archived_sessions のロールアウト JSONL の 1 行目：session_meta.payload.model_provider
• アプリの SQLite ストア：$env:USERPROFILE\.codex\sqlite\state_5.sqlite
• レガシー CLI の SQLite ストア：$env:USERPROFILE\.codex\state_5.sqlite
• アプリのストアに存在しない一方、レガシー CLI のストアには残っているスレッド行を、レガシー CLI のストアから新しいアプリのストアに補完します。
• ロールアウトの 1 行目から参照されているものの存在しない過去の cwd ディレクトリ。これは -RepairMissingCwdDirs を明示的に指定した場合に限ります。

信頼できるデータに関する重要な詳細：

• Codex 26.609 以降は、起動時にロールアウト JSONL から state_5.sqlite を再構築できます。ロールアウトの 1 行目にある session_meta.payload を永続的なメタデータとして扱い、アプリの SQLite 行だけを信頼できるデータと見なさないでください。
• 当前工作目录缺失 は、片方の SQLite ストアだけを変更して修復しないでください。再起動するまでは UI 上で修復されたように見えても、その後のバックフィルやロールアウトの読み込みによって、古い値が再び反映される可能性があります。
• 履歴メタデータを書き換える前に、元の存在しない cwd ディレクトリを空のディレクトリとして再作成することを優先してください。これによりロールアウト履歴が保持され、復元されて表示されるものの続行できない会話が修復されることを確認済みです。 変更を加える前に、ドライランを実行します。

powershell -NoProfile -ExecutionPolicy Bypass -File "$SkillRoot\scripts\sync-codex-provider-history.ps1" -DryRun

書き込み方法を選択する前に、ドライランの出力を確認します。

• プロバイダーのバケットに不一致が表示された場合は、Codex Desktop を閉じるか停止してから、同期を実行します。
• サイドバーに復元された会話がすでに表示されているものの、作業ディレクトリが見つからないためスレッドを続行できない場合は、missing rollout cwd dirs before を確認します。見つからない cwd エントリが一覧表示されている場合は、-RepairMissingCwdDirs を使用します。
• 見つからない cwd パスが現在のユーザープロファイルの外部にある場合、デフォルトでは作成しないでください。まずパスを確認し、ローカルの想定されたパスである場合にのみ -AllowCwdOutsideUserProfile を渡します。

プロバイダー同期の書き込み方法：

Get-Process Codex,ChatGPT -ErrorAction SilentlyContinue | Where-Object { $_.Path -like 'C:\Program Files\WindowsApps\OpenAI.Codex_*\app\Codex.exe' -or $_.Path -like 'C:\Program Files\WindowsApps\OpenAI.Codex_*\app\ChatGPT.exe' } | Stop-Process -Force
powershell -NoProfile -ExecutionPolicy Bypass -File "$SkillRoot\scripts\sync-codex-provider-history.ps1"

見つからない cwd の修復方法：

Get-Process Codex,ChatGPT -ErrorAction SilentlyContinue | Where-Object { $_.Path -like 'C:\Program Files\WindowsApps\OpenAI.Codex_*\app\Codex.exe' -or $_.Path -like 'C:\Program Files\WindowsApps\OpenAI.Codex_*\app\ChatGPT.exe' } | Stop-Process -Force
powershell -NoProfile -ExecutionPolicy Bypass -File "$SkillRoot\scripts\sync-codex-provider-history.ps1" -RepairMissingCwdDirs

これにより、rollout の先頭行で参照されている見つからないディレクトリのみが作成されます。これらの cwd 値は書き換えず、config.toml が変更されていないことも引き続き検証します。デフォルトでは、他のドライブやネットワーク共有に予期しないルートが作成されないよう、$env:USERPROFILE の外部にある cwd パスはスキップします。

ガードレール：

• config.toml は変更しないでください。スクリプトは各実行の前後でファイルのハッシュを確認し、変更されていた場合は失敗します。
• このワークフローで外部の復旧ツールをインストールしたり、起動したりしないでください。必要なローカルメタデータの修復は、スクリプトが直接実行します。
• この症状に対して ASAR にパッチを適用したり、フローティングセッションリストを注入したりしないでください。別のフローティングパネルでセッションを表示できますが、これは公式のサイドバー復旧方法ではなく、UI やエンコーディングの不具合を引き起こす可能性があります。
• デフォルトでは .codex-global-state.json のワークスペース／プロジェクトのルートを同期しないでください。同期すると、過去の多数の cwd 値が Desktop のサイドバーに空のプロジェクトグループとして表示される可能性があります。
• rollout の cwd を書き換えたり、見つからないすべての cwd 値を Documents\Codex などのフォールバックディレクトリに強制的に設定したりしないでください。まず元の見つからないディレクトリパスの復元を試します。過去の cwd の書き換えは、ディレクトリの復元に失敗した場合に限り、別途バックアップを取ったうえで最後の手段として行います。
• SQLite または rollout への書き込み前に、バックアップは $env:USERPROFILE\.codex\backups_state\history-sync-agent\<timestamp> に保存されます。
• 読み取れない、または空の rollout 先頭行は、1 行に限りスキップされることがあります。SQLite と読み取り可能な rollout の件数が一致し、公式サイドバーに想定される会話が表示されていれば、失敗ではなく残存データの問題として扱ってください。

成功基準：

• スクリプトが現在の設定から対象プロバイダーをログに記録します。
• App と旧形式の両方の SQLite ストアが存在する場合、それぞれで対象プロバイダーのアクティブなスレッド行とアーカイブ済みのスレッド行が報告されます。
• 読み取り可能な rollout について、sessions と archived_sessions 内の先頭行にあるプロバイダーの件数が対象プロバイダーと一致します。
• config.toml sha256 unchanged がログに記録されます。
• 再起動後、Codex Desktop の公式サイドバーに復元された過去の会話が表示されます。
• 表示上は会話が復元されているものの続行できない症状の場合、missing rollout cwd dirs after がゼロ件、または確認済み／スキップ済みのパスのみを報告し、Desktop の再起動後に該当する会話で新しいターンを送信できます。
• Projects／workspace 領域に、副作用として新しい空のプロジェクトグループが追加されません。

重要なガードレール

• メインの完全修復インストーラーは、共有のガード付きインストーラーを呼び出す前に、圧縮解除されたすべての MSIX ペイロードブロックを検証します。すべての事前チェックが完了した後、パッケージのリビジョンをインクリメントし、既存のパッケージに対して Add-AppxPackage -ForceApplicationShutdown を使用してデプロイします。デプロイに失敗しても既存のパッケージ登録は維持されます。アンインストールへの自動フォールバックは追加しないでください。有効な Authenticode 署名だけでは、ペイロードとブロックマップの整合性は証明できません。この方法は、パッケージの制約を受ける Desktop コードにのみ使用してください。ローカルの Chrome／Computer Use の失敗には、Computer Use Only ワークフローを使用してください。
• 完全修復ラッパーは、最終的なパッケージがパッチ適用時のパッケージバージョンと一致し、SignatureKind = Developer であることを検証します。修復中に Store がパッケージを置き換えた場合、誤って成功を報告する代わりに、現在のパッケージに対して一度だけ再試行します。二度目の置き換えが発生した場合は、対処方法が分かるエラーを表示して失敗します。
• C:\Program Files\WindowsApps を直接変更しないでください。MSIX 再パッケージスクリプトを使用してください。
• Windows 10 の SetIsBorderRequired／0x80004002 によるスクリーンショットの失敗を、古い Codex Desktop パッケージの復元や、別のランタイムからヘルパーをコピーすることで解決しないでください。バンドルされている各ヘルパーのパッチプロファイルは、ドキュメントに記載された正確な入力／出力ハッシュの組み合わせに限定されます。元のファイルをバックアップし、未知のバイナリは拒否します。
• list_windows、runtime import ok、返されたスクリーンショットの数、書き込まれた PNG を、Computer Use によるキャプチャが正しいことの証拠として扱わないでください。node_repl exec context not found の場合、リクエストコンテキストのパッチ適用後に、後続の独立した呼び出しが成功することを確認してください。キャプチャの直前に対象をアクティブ化して再検証し、画像の内容が対象と一致しており、手前に重なっているウィンドウではないことを確認してください。
• 電話のリモート操作用 MSIX パッチを、既定の再パッチ処理の副作用として実行しないでください。電話のリモート操作タスク、またはユーザーがそのワークフローを明示的に依頼した場合にのみ使用してください。
• すべての missing field inputSchema を MCP の問題として扱わないでください。CLI のスモークテストは成功する一方で Desktop UI が失敗し、Dynamic Tools の ASAR アセットが引き続き名前空間ラッパーを返す場合は、無関係な MCP サーバーを無効化するのではなく、Dynamic Tools Schema ワークフローを使用してください。
• FAST_CHECK_OK のような応答を Fast Mode の証拠として信用しないでください。信用できるのは、分離された一時的な CODEX_HOME を使用し、CLI の /v1/models プローブを提供したうえで、/v1/responses の HTTP 本文または WebSocket フレームをキャプチャし、service_tier=priority を確認するラッパー／スクリプトのワイヤー検証だけです。models のみのリクエストは証拠になりません。リクエスト送信前に codex exec が終了またはクラッシュした場合、検証ツールは codex debug app-server send-message-v2 にフォールバックし、thread/start serviceTier=priority も確認する必要があります。ワイヤーキャプチャは引き続き必須です。PATH によって保護された WindowsApps の CLI しか見つからない場合、パッチ適用ツールはコピーされた作業パッケージの CLI を使用する必要があります。明示的な検証要求があるときは、実行可能な CLI がなければ、黙ってスキップせず失敗しなければなりません。
• %USERPROFILE%\.codex\logs_2.sqlite 内のキーワードのヒットを、現在インストールされているパッケージにパッチが適用されている証拠として信用しないでください。タスクのプロンプトや記録されたツール呼び出しには、local-patched、already-patched、パッチマーカー名などの文字列が残ることがあり、誤検出につながります。パッチ状態の判断には、現在のパッチ適用ツールの DryRun、稼働中のパッケージ／ASAR からの直接的な証拠、実際のワイヤー、UI、ブラウザー、またはランタイムのスモークテストを使用してください。ただし、現在のパッケージ、プロセス、テスト実行と関連付けられたタイムスタンプ付きの Desktop ランタイムログは、この制限の対象外です。この確認のために logs_2.sqlite を削除または変更しないでください。
• アプリが起動直後に終了する場合は、Electron のログ記録を有効にして、ASAR の整合性エラーを確認してください。

$pkg = Get-AppxPackage -Name OpenAI.Codex | Select-Object -First 1
$manifest = [xml](Get-Content -Raw -LiteralPath (Join-Path $pkg.InstallLocation 'AppxManifest.xml'))
$desktopExecutable = [string](($manifest.Package.Applications.Application | Select-Object -First 1).Executable)
$exe = Join-Path $pkg.InstallLocation $desktopExecutable
$env:ELECTRON_ENABLE_LOGGING='1'
Push-Location (Split-Path -Parent $exe)
& $exe --enable-logging=stderr --v=1 2>&1 | Select-String -Pattern 'FATAL|Integrity|asar|ERROR'
Pop-Location
Remove-Item Env:ELECTRON_ENABLE_LOGGING -ErrorAction SilentlyContinue

• makeappx.exe または signtool.exe が見つからない場合は、ラッパーを通常どおり実行してください。Windows SDK が一時的にインストールされ、実行後に削除されます。
• ドライランまたは再パッケージ化が robocopy failed with exit code 16 で早期に失敗する場合は、パッチ対象を変更する前に、設定済みの -OutputRoot を確認してください。Windows でよくある原因は、削除済みのビルドディレクトリを指す Downloads\codex-msix-repack などの壊れたジャンクションです。パッチスクリプトは、可能な場合は欠落した再解析ポイントの参照先を再作成し、そうでない場合は OutputRoot is a broken reparse point という具体的なメッセージを表示して早期に失敗するようになりました。既定値を修復できない場合は、ローカルの大容量ドライブ上にある有効な -OutputRoot を指定してください。
• ローカルのマーケットプレイスディレクトリが見つからない場合、マーケットプレイスを捏造しないでください。欠落しているパスを報告し、バックアップから復元するか、既知のソースから再抽出するかを尋ねてください。
• ユーザーレベルの Codex の状態のバックアップまたは移行には、scripts\manage-codex-backups.ps1 を使用してください。config.toml、抽出済みの mcp_servers.json、カスタムスキル、マーケットプレイス、chrome-native-hosts.json をバックアップします。既定では .git、node_modules、ビルド出力、仮想環境は除外されます。オフラインで正確な依存関係のコピーが必要な場合に限り、-IncludeDependencyDirs を使用してください。プラグインキャッシュと .tmp\bundled-marketplaces も大容量になる可能性があるため、オプトイン方式です。
• codex plugin list が failed to load configured marketplace snapshot(s) で失敗し、ローカルのマーケットプレイスルートに marketplace.json しかない場合は、そのマニフェストを .agents\plugins\marketplace.json にコピーし、個別のプラグインを診断する前に codex plugin list を再実行してください。
• Downloads\patch_codex_fast_mode_windows_msix.ps1 に依存しないでください。このスキルは自己完結型です。ユーザーが明示的に -PatchScript を渡さない限り、scripts\patch_codex_fast_mode_windows_msix.ps1 を使用してください。
• ユーザーが明示的に求めない限り、同梱のカスタム model_instructions_file プロンプトを有効にしないでください。assets\system-prompt.md は内容をそのまま扱うアセットとして扱ってください。別途プロンプトの確認を求められない限り、その内容を調べたり要約したりせず、コピーまたは設定してください。
• Codex 26.601.2237+ では、Fast Mode が webview\assets\read-service-tier-for-request-*.js 内で、return authMethod===\chatgpt` ? featureRequirements?.fast_mode !== false : false のような非同期ヘルパーによって制御されている場合があります。パッチでは、モデル／ホストの機能要件を引き続き読み取りながら、chatgpt` のみを対象とする分岐を削除し、その後ワイヤーキャプチャで確認してください。
• Codex 26.601.2237+ では、Fast Mode が webview\assets\use-service-tier-settings-*.js によって設定 UI 上で非表示または無効のままになる場合もあります。パッチでは Fast UI パッチャーを接続し、リクエストヘルパーだけでなく fast-mode UI patch result をログに記録してください。
• 再起動後に言語設定が英語に戻る場合は、抽出した WebView アセット内の enable_i18n、locale_source、localeOverride を確認してください。ロケールパッチでは locale i18n patch result をログに記録してください。設定ファイルに言語を書き込むだけでは不十分です。
• ブラウザー、Chrome、ブラウザーペイン、または browser_use が引き続き利用できない場合は、Desktop のログで browser_use_availability_resolved を確認してください。reason=statsig-disabled は、ローカルゲートのパッチが適用されなかったか、Store ビルドで対象の形状が変更されたことを意味します。reason=local-patched は利用可否ゲートが開いていることを意味し、次に Chrome 拡張機能、ネイティブメッセージングホスト、同梱プラグインの状態を確認してください。
• Codex 26.601.2237+ では、古いプラグイン UI ゲートの対象である 533078438 と pluginDeepLinkAuthBlocked が存在しない場合があります。webview\assets\plugins-page-*.js で openPluginInstall、authMethod:、および {authMethod:x}=..., y=authBlocked(x), のようなコンパクトな代入を確認してください。古いサイドバー／スキル／詳細チャンクが見つからないことで失敗させるのではなく、認証ブロック変数を false にパッチしてください。
• Codex 26.616.3767+ では、plugins-page-*.js 内で authMethod と認証ブロック変数の間にアカウントデータフックが挿入され、{authMethod:x}=authHook(),{data:y}=accountHook(),z=authBlocked(x), のような形になる場合があります。挿入されたフックを保持し、認証ブロック変数だけを false にパッチしてください。
• Codex 26.616.3767+ では、Goal スラッシュコマンドに古い 3074100722／goals 設定ゲートや threadGoalObjective アンカーが含まれない場合があります。たとえばコンポーザーが、enabled に渡される isGoalActionAvailable などを通じて、クラウド以外の／ローカルの状態から Goal の利用可否を計算している場合、その形はすでに開放済みとして扱い、MSIX ドライランを失敗させないでください。
• Codex 26.616.3767+ では、use-is-plugins-enabled-*.js の featureName:\browser_use`とfeatureName:`browser_use_external` のセマンティクスは同じでも、機能フック、Statsig、runCodexInWsl の読み取りに使われる難読化後のヘルパー名が異なる場合があります。固定のヘルパー識別子（x、g、u など）に依存せず、featureName、enabled、isLoading、410262010、runCodexInWsl` 周辺の形状でゲートを照合してください。
• Codex 26.707.3748.0 では、Desktop の機能送信側が externalBrowserUseAllowed と computerUse の間に findShortcuts を挿入する場合があります。ブラウザー利用可否のフィールドを強制する際はそのフィールドを保持し、computerUse が externalBrowserUseAllowed の直後に続くことを必須にしないでください。
• Codex 26.707.8479.0 では、Electron の機能受信側で、古い固定の i プラットフォーム変数ではなく、o=r===\win32`&&n.CODEX_ELECTRON_ENABLE_WINDOWS_COMPUTER_USE...` のようなパラメーター化された難読化変数が使われています。難読化識別子をハードコードせず、代入、プラットフォーム変数、環境オブジェクト、基本機能オブジェクトの構造で照合してください。
• Codex 26.707.8479.0 では、plugins-page-*.js 内で {authMethod:x}=...() と認証ブロックの代入の間に、ワークスペース／アカウントの導出処理が置かれる場合があります。後続の route.kind===\manage`` 境界を使ってブロック代入を特定し、その変数だけをパッチしてください。間にあるフックや導出済み状態はすべて保持してください。
• Codex 26.519.11010+ では、use-plugin-install-flow-*.js に featureName:\computer_use` が含まれない場合があります。Computer Use のインストールフローゲートでは、installPlugin:asyncとopenPluginInstallを含むファイルを特定し、インポートされた利用可否タプルのうち、Computer Use に対応する最初の.available` 値を強制的に true にしてください。
• Codex 26.707.8479.0 では、Computer Use のインストールフローが plugin-detail-page-utils-*.js に移動し、リテラルの installPlugin:async プロパティが、難読化された非同期ミューテーション内の install-plugin RPC に置き換わる場合があります。いずれかのアンカーを受け入れ、openPluginInstall を必須とし、3 つの値からなる利用可否タプルの最初の値だけにパッチしてください。
• Codex 26.707.8479.0 では、同梱マーケットプレイスのコピーヘルパーが、すでに windows-file-copy-*.js の copyDirectoryAllowDecryptedDestinationOnEncryptionFailure 経由で Windows に対応している場合があります。このネイティブの Windows フォールバックは修復済みとして扱い、古いバイトストリーム方式のフォールバックに置き換えないでください。必要に応じて、独立した同梱 sites 利用可否パッチは引き続き適用してください。
• Computer Use を有効にするために、C:\Program Files\WindowsApps を直接変更しないでください。Windows のゲートは CODEX_ELECTRON_ENABLE_WINDOWS_COMPUTER_USE=1 で制御され、ヘルパーのパスはローカルの computer-use@openai-bundled プラグインから提供されます。
• Computer Use、または node_repl の Computer Use プラグインが Windows で windows sandbox failed: spawn setup refresh により失敗する場合は、$env:USERPROFILE\.codex\.sandbox\sandbox.<date>.log を確認してください。codex-windows-sandbox-setup.exe が OS エラー 740 で失敗している場合は、[windows] sandbox = "unelevated" を設定してください。検証前に codex sandbox --help を確認してください。ヘルプに windows コマンドが記載されている場合は、codex sandbox windows "C:\Windows\System32\cmd.exe" /c echo OK で検証してください。ヘルプで直接コマンド形式が受け付けられるビルドに限り、codex sandbox "C:\Windows\System32\cmd.exe" /c echo OK を使用してください。
• Computer Use のタスクがアプリの操作前に Package subpath ... is not defined by "exports"、Module not found: @oai/sky、setupComputerUseRuntime の欠落、または内部の @oai/sky／computer_use_client_base インポートパスエラーで失敗する場合は、ローカルの同梱プラグイン／ランタイムの不整合として扱ってください。scripts\install-computer-use-local.ps1 -VerifyOnly を実行し、続けて -StrictVerifyOnly を実行してください。この種の問題では、Desktop のログから UI の利用可否ゲートも閉じていることが確認できない限り、app.asar や resources\codex.exe にパッチを適用しないでください。
• 「任意アプリ」が表示されているものの、組織／地域で利用できないため無効になっている場合は、抽出した ASAR 内の webview\assets\use-is-plugins-enabled-*.js を確認してください。該当するローカルゲートは featureName:\computer_use`と Statsig1506311413` です。WindowsApps を直接編集するのではなく、MSIX パッチを再適用してください。
• Computer Control ページに Computer Use 插件不可用 と表示される場合は、Desktop のログで computer-use native pipe startup failed と missing-helper-path の組み合わせを確認し、その後 [marketplaces.openai-bundled] の下に設定されている source と、その .agents\plugins\marketplace.json および plugins\computer-use を確認してください。それらが欠落しているか不完全な場合は、$env:USERPROFILE\.codex\plugins\cache\openai-bundled 配下の同梱 extension-host プロセスを停止し、scripts\install-computer-use-local.ps1 を再実行して、Codex Desktop を再起動し、ログの最後が computer-use native pipe startup ready であることを確認してください。
• 現行の Codex ビルドでは、使用可能な latest ジャンクションもプラグインローカルの node_modules もない、軽量なバージョン付き Computer Use キャッシュを使用する場合があります。@oai/sky は %LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node にあります。一部のビルドは記述子のみで、scripts\computer-use-client.mjs を含みません。バージョン付き記述子がインストール済みパッケージと一致し、独立したランタイムをインポートすると sky.list_windows が利用できて配列を返す場合、この構成は正常として扱ってください。認識済みの @oai/sky 0.6.2 Window2 プロファイルでは、同梱ランタイムのドキュメント呼び出しに依存しないでください。修復では、list_windows、get_window_state({ window, ... })、activate_window({ window }) を使用する、ガード付きのローカルスキルオーバーレイを適用します。クライアントスクリプトを引き続き同梱するビルドでは、従来のクライアントインポートとヘルパー転送のチェックを維持してください。
• Codex Desktop を完全に終了して再度開いた後に問題が再発する場合は、$env:USERPROFILE\.codex\chrome-native-hosts.json、%LOCALAPPDATA%\OpenAI\Codex\chrome-native-hosts-v2.json と $env:USERPROFILE\.codex\chrome-native-hosts-v2.json の両方、さらに $env:USERPROFILE\.codex\plugins\cache\openai-bundled\chrome\latest と browser\latest の実際の参照先を確認してください。外側のマニフェストと extension-host-config.json が正しくても、両方の v2 状態ファイルに古いパッケージ／ランタイムパスしか含まれていない場合や、現在のエントリのハッシュが誤っている場合は、Codex app-server manifest entry is missing required path nodePath などのサイドパネルエラーが残ることがあります。新しい Chrome プラグインビルドでは、バージョン付きキャッシュパスを chrome\latest に正規化する場合があります。ジャンクションがバージョン付きキャッシュディレクトリを参照している場合に限り、これは許容されます。Chrome ネイティブホストの古いエントリや、$env:USERPROFILE\.codex\.tmp\bundled-marketplaces\openai-bundled\plugins\chrome を参照する chrome\latest ジャンクションによって、Chrome のネイティブメッセージングが変更可能なマーケットプレイスミラーをロックする場合もあります。scripts\install-computer-use-local.ps1 を再実行してロックを保持しているプロセスを停止し、安定した browser／chrome キャッシュコピーを再構築し、外側のマニフェストの参照先を変更して、両方の v2 状態ファイルをアトミックに同期してください。
• 変更可能な .tmp\bundled-marketplaces ミラーから、安定した browser、chrome、sites、または基本の computer-use キャッシュを構築しないでください。ファイルのコピー中に Desktop がそのミラーを再調整する場合があります。安定したソースにはインストール済みパッケージのマーケットプレイスを使用し、その後、ローカルの Computer Use ランタイムをバージョン付きキャッシュに直接オーバーレイしてください。
• 再起動後に、copy_plugins 中の plugin_marketplace_folder_write_failed、bundled_plugins_marketplace_resolve_failed、または以前インストールした同梱プラグインを削除する not_in_bundled_marketplace_plugin_names によって問題が再発する場合は、Fast／browser／Computer Use ゲートの全面的な再パッチを実行せず、同梱マーケットプレイスのコピー用ヘルパーだけにパッチを適用してください。この対象を絞ったパッチでは、パッケージ記述子のセットをローカルで利用できる状態に保ちますが、ユーザーが選択していないオプションのプラグインをインストールしたり有効にしたりしてはいけません。

powershell -NoProfile -ExecutionPolicy Bypass -File "$SkillRoot\scripts\patch_codex_fast_mode_windows_msix.ps1" -OnlyBundledMarketplaceCopy -DryRun -OutputRoot "<large-local-build-root>"
powershell -NoProfile -ExecutionPolicy Bypass -File "$SkillRoot\scripts\patch_codex_fast_mode_windows_msix.ps1" -OnlyBundledMarketplaceCopy -Install -Launch -InstallPrerequisites -OutputRoot "<large-local-build-root>"

ローカルの Computer Use ランタイムで install-computer-use-local.ps1 -StrictVerifyOnly が成功したにもかかわらず、Desktop に cua.computer.* サーフェスが表示されない場合は、まず現在の ASAR で、サポート対象となる Darwin 限定のゲートが両方あるか確認してください。両方が存在する場合に限り、以下の対象を絞ったメイン ASAR モードを使用してください。このモードは、より広範な Fast Mode／ブラウザ／プラグインのパッチセットとは意図的に分離されています。

powershell -NoProfile -ExecutionPolicy Bypass -File "$SkillRoot\scripts\patch_codex_fast_mode_windows_msix.ps1" -OnlyComputerUseSurface -DryRun -OutputRoot "<large-local-build-root>"
powershell -NoProfile -ExecutionPolicy Bypass -File "$SkillRoot\scripts\patch_codex_fast_mode_windows_msix.ps1" -OnlyComputerUseSurface -Install -Launch -InstallPrerequisites -OutputRoot "<large-local-build-root>"

このモードでは、コンテンツが一致する .vite\build の対象がちょうど 1 つであること、および各オリジナルゲートが 1 回ずつ出現することが必要です。冪等性を保つには、パッチ適用済みの完全なゲートが両方存在し、CODEX_CUA_WINDOWS_SURFACE_V1 マーカーが 1 つあり、オリジナルゲートが存在しないことが必要です。マーカーのみの場合、状態が混在している場合、または候補が重複している場合は、安全のため処理を中止します。従来の Windows レイアウトでは、computerUse と computerUseNodeRepl の両方が維持されます。後者のフラグがない Desktop 26.917 レイアウトでは、n.Gu や n.Wu などの名称変更されたインポート／エクスポートシンボルを許容し、完全な統合 CUA の準備完了述語が 1 回一致する必要があります。以前のパッチが完全に適用されている場合は、ホストのレイアウトに適した式へ移行します。以前のパッチで追加された依存関係は、ホストが引き続きそのフラグをサポートしている根拠にはなりません。Darwin の動作は変更されません。パッチ適用済みのアセットは node --check に合格する必要があります。このモードでは、無関係な Chrome レジストリのパッチはスキップされ、他の対象限定モード、マーケットプレイス登録、Fast Mode 検証、スクリーンショットヘルパーのパッチ適用との併用は拒否されます。プラグインキャッシュファイル、.mcp.json、ユーザー設定は編集しません。通常の再パッケージでは、コピーされたパッケージの ASAR 整合性メタデータと署名が引き続き更新されます。インストール／再起動は外部の実行環境から行う必要があります。

フィクスチャでの成功やインストール済みパッケージでのドライランだけでは、実際の Desktop との対話を確認したことにはなりません。再起動後、新しい会話で Object.keys(cua) を調べ、既定のバックグラウンドチェックとしてウィンドウを列挙してください。@oai/cua 0.2.5 では、cua.listWindows() がこのチェックに対応しています。明示的に許可されたキャプチャ／入力診断に限り、cua.getApp({ windowId: <real id> }) または低レベルのウィンドウ API を使用してください。getApp に文字列引数を渡す形式は macOS 用です。承認 UI、スクリーンショットの内容、アクセシビリティ、入力はそれぞれ別個に記録し、未検証の項目はその旨を明記してください。

Windows では、高レベルのバインド済み getScreenshot() が、ウィンドウについて multiple screenshot regions; a single screenshot is unavailable というエラーを返すことがあります。Desktop 26.917.9434.0 では、Explorer のウィンドウに対して 2 つの領域が返されましたが、低レベルの cua.computer.get_window_state() からは両方の表示中スクリーンショットとアクセシビリティ状態が返されました。高レベルの単一画像エラーをネイティブの Computer Use の失敗と見なすのではなく、screenshots[] の領域と対象ウィンドウの内容を確認してください。Sky がウィンドウ内でユーザーの入力が同時に行われていると報告した場合は、ユーザーの操作を上書きせず、入力を停止してください。

便利なラッパーオプション

• -PatchWindowsStoreUpdateFallback：Desktop のログに新しい公式マニフェストが表示されている一方、Store が NoUpdates を報告する場合に限り、オプトインしてください。サポート対象の 26.928 ブランチでは、最新であると報告する代わりに、既存の公式 MSIX フォールバックを呼び出します。まず完全な DryRun を実行してください。このオプションが変更するのは Codex のアップデーターであり、Windows Store のタスクやポリシーではありません。Windows Store のダウンロードフォールバックを参照してください。

• -DryRun：バンドルの対象のみを検証し、インストールは行いません。-KeepBuild が指定されていない場合、パッチ適用ステージが成功した後に、ラッパーはパッチ適用ツールに対し、コピーしたビルドルートをクリーンアップするよう指示します。クリーンアップはベストエフォートで行われます。残存データをゼロにする必要がある場合は、報告されたパスを確認してください。パッチ適用ツールが自身のビルドルートをすでにクリーンアップした後でも、ラッパーによる後続の検証が失敗することがあります。

• -NoLaunch：インストールしますが、Codex Desktop は起動しません。

• -SkipFastVerify：ローカルの HTTP／WebSocket による service_tier の取得をスキップします。

• -CustomModels <id1,id2,...>：Desktop のモデル表示フィルターを通過させるカスタムモデル ID です。既定値は gpt-6-astra、gpt-6-sol、gpt-5.6-sol、gpt-5.6-terra、gpt-5.6-luna です。ラッパーとメインのパッチ適用ツールはどちらも、カンマ区切りの ID または PowerShell の文字列配列を受け付けます。このパラメーターを渡すと、以前に適用したパッチが完全なものであっても既定のリストが置き換えられるため、新しいモデルと一緒に引き続き使用するモデルも指定してください。空の項目は削除され、重複する ID は重複排除されます。

• -KeepBuild：DryRun またはインストール後のデバッグ用に、ラッパーの MSIX ビルドルートと保持されたアーティファクトを残します。パッチ適用ツール内部の一時 ASAR 作業ディレクトリには、引き続き独自のクリーンアップポリシーが適用されます。

• -OutputRoot <path>：任意の大容量ローカルビルドルートです。既定の出力ルートの空き容量が不足している場合、壊れたジャンクションを指している場合、またはシステムドライブ以外に配置したい場合に使用します。

• -OnlyBundledMarketplaceCopy：Desktop にバンドルされたマーケットプレイスのコピー／ヘルパー利用可能性の経路のみを修正します。これにより、WindowsApps で保護されたパッケージパスからバンドルされたプラグインファイルを fs.cp() でコピーできない場合、Windows はバイトストリームコピーにフォールバックします。また、機能の述語によって除外される場合に、sites、deep-research、Code Review、統合 Computer Use のサポート対象となるオプションのマーケットプレイスエントリを復元します。これらのエントリを公開しても、インストールされたり、ブラウザーエンジンが切り替わったりすることはありません。実際に確認されたバンドル済みマーケットプレイスの同期または検出の失敗に対して使用してください。一般的な Fast Mode や UI のゲートには使用しないでください。

• -OnlyComputerUseSurface：現在のメイン ASAR にある、Darwin のみを対象とする Windows Computer Use のサーフェスゲートのみを修正します。まず -DryRun を使用してください。バンドルのアンカーが見つからない場合、または曖昧な場合は、安全側に停止します。

• -OnlyModelExperience：Fast Mode のリクエストゲート、Fast Mode の UI ゲート、カスタムモデル表示フィルター、コンパクトな Power スライダーのゲート、Ultra 設定の永続化をまとめて検査し、選択的に修正します。Fast Mode、非表示のカスタムモデル、それに依存するコンパクトな Power スライダー、カスタムプロバイダーで無効になっている Ultra トグルに使用します。旧名の -OnlyCustomModels もエイリアスとして引き続き使用できます。

• 26.1007 の DryRun で fastModeTarget が見つからないと報告された場合は、references/restriction-debug-cases.md のサービス層アクセスオブジェクトのケースを確認してください。このバージョンでは、以前のインラインのブール値ゲートではなく、共有コンバーターに両方の速度モードを委譲します。

• -SkipSdkCleanup：Windows SDK をインストールしたままにします。

• -RegisterMarketplaceOnly：openai-curated-local のみを登録し、Codex は修正しません。

• -PatchScript <path>：新しいパッチ適用ツールをテストする場合に限り、バンドルされたパッチスクリプトを上書きします。

• -SkipComputerUse：ローカルの Computer Use 互換プラグインのインストール／検証をスキップします。

• -PatchWindows10ScreenshotHelper：Windows 10 で SetIsBorderRequired / 0x80004002 または FrameArrived timed out を再現した場合に限り、完全な MSIX 修復中にステージング済みネイティブヘルパーを明示的に修正します。ラッパーとメインのパッチ適用ツールの両方で使用できます。既定ではヘルパーは変更されません。明示的に要求した場合、未知のハッシュは拒否され、対象を限定するモードとの併用はできません。

• ラッパーは、上記で説明されている、正確に一致するパッケージゲートによる trusted-paths エラーの場合に限り、Computer Use の事前チェックを続行できます。ローカルのランタイム修復とパッケージのパッチ適用を意図的に分ける場合にのみ、-SkipComputerUse を使用してください。

• -VerifyAllBundledPluginsAvailable：安定した openai-bundled ディスクリプターの名前とバージョンがインストール済みパッケージと完全に一致し、すべてのエントリが構造化 CLI 出力に、インストール済み、または既存のローカルソースを持つ利用可能な項目として、そのバージョンとともに表示されることを確認するアサーションを追加します。このアサーションが plugin add を呼び出すことはありませんが、メインのラッパーは通常どおり修復または DryRun を実行します。完全な読み取り専用チェックを行うには、install-computer-use-local.ps1 -StrictVerifyOnly -VerifyAllBundledPluginsAvailable を直接実行してください。

• -InstallModelInstructionsFile：任意です。バンドルされたプロンプトアセットを $env:USERPROFILE\.codex\prompts\system-prompt.md にコピーし、$env:USERPROFILE\.codex\config.toml のトップレベルに model_instructions_file を設定します。

• -ModelInstructionsSource <path>：-InstallModelInstructionsFile の任意のソース上書きです。既定値は assets\system-prompt.md です。

• -ModelInstructionsDestination <path>：-InstallModelInstructionsFile の任意のコピー先上書きです。既定値は $env:USERPROFILE\.codex\prompts\system-prompt.md です。 Phone リモート制御スクリプトのオプション：

• scripts\build-remote-control-native-replacement.ps1 -WorkRoot <path>：選択した作業ルートの下でネイティブ版の代替をクローン、パッチ適用、ビルドします。Cargo／Rustup／一時ファイル／ターゲット／ソースのアーティファクトと、フォールバック用の Windows SDK C++ NuGet キャッシュをシステムドライブに置かずに済みます。両方のバージョンパラメーターを省略すると、一時的な WorkRoot コピーからインストール済みのネイティブ版のバージョンを自動検出します。検出したバージョンにマッピングがない場合は、0.144 と決めつけず、明示的なパラメーターを要求します。

• -CodexSourceRef <rust-vX> -AppServerVersion <X>：自動検出を上書きする場合は、必ず完全に一致するペアで指定してください。0.145.0-alpha.18 は Desktop 26.715.2305.0 で、正確なタグを使ったビルド、インストール、Phone の一連の動作まで検証済みです。0.144.0-alpha.4 も Desktop 26.707.3748.0 で同じ範囲の検証が済んでいます。専用の 0.142.4 パッチはパッチ適用まで検証済みですが、このワークフローではまだ完全なコンパイルを行っていません。

• -PatchPathOverride <path>：完全に一致するソース参照／app-server バージョンのペアと組み合わせ、指定したパッチがそのソースを対象としていることを検証した後にのみ使用してください。コンパイル前にパッチの適用もチェックされます。

• -SkipBuild：codex.remote-control-build.json を伴う、以前に生成されたバイナリのみを再利用します。ヘルパーは、Git コミット、ソース参照、app-server バージョン、パッチの SHA-256、Rust ツールチェーン、ターゲット、プロファイル、バイナリの --version、ネイティブのマーカーが完全に一致することを検証します。マーカーしかないバイナリや、スタンプのない古いバイナリは拒否されます。このモードでは Windows SDK の初期化やダウンロードは行いません。

• scripts\patch-remote-control-windows-msix.ps1 -DryRun：抽出したパッケージにパッチを適用して検証します。インストールは行わず、成功した生成アーティファクトをクリーンアップします。

• -KeepWorkDir：デバッグ用に MSIX のステージング領域、ASAR の展開データ、スクリプトローカルの npx キャッシュを保持します。実行ごとに数 GB を消費する可能性があるため、通常の修復では使用しないでください。

• -OutputRoot <path>：任意の大容量ローカルビルドルートです。既定の一時／出力ドライブの空き容量が不足している場合に使用してください。

• -ReplacementResourceCodexExe <path>：パッチ適用済みのネイティブ app-server バイナリをコピーし、パッケージ化の前にリモート制御のマーカーを検証します。

• -Install -Launch -InstallPrerequisites：Dry-run が通った後、パッチ適用済みパッケージに署名、インストールし、再起動します。

Dynamic tools スキーマスクリプトのオプション：

• scripts\patch-dynamic-tools-windows-msix.ps1 -DryRun：現在のパッケージを抽出し、app-server-dynamic-tools-*.js にパッチを適用して検証します。node --check を実行した後、インストールせずに成功した生成アーティファクトをクリーンアップします。
• -OutputRoot <path>：任意の大容量ローカルビルドルートです。システムドライブの空き容量が不足している場合に使用してください。
• -Install -Launch -InstallPrerequisites：Dry-run が通った後、対象の dynamicTools パッチ適用済みパッケージに署名、インストールし、再起動します。
• -KeepWorkDir：デバッグ専用として、MSIX のステージング領域、ASAR の展開データ、スクリプトローカルの npx キャッシュを保持します。

オプションのモデル指示ファイル

このワークフローには、オプションのカスタムモデル指示インストーラーがあります。これはデフォルトの repatch フローには含まれず、ユーザーが追加の設定を求めた場合にのみ実行してください。

ユーザー向けの名称「Tinghuashui」は、既存のバンドル済みシステムプロンプト設定を指します。「Tinghuashui を設定して」や「Tinghuashui 関連の設定を手伝って」などの依頼では、このワークフローを選択してください。この依頼に限り、以下のスタンドアロンインストーラーを assets/system-prompt.md とともに使用してください。置き換え用のプロンプトを生成したり、Desktop の repatch を実行したりしないでください。バンドル済みのプロンプト内容は変更しないでください。

バンドル済みのプロンプトアセットのみをインストールし、Codex を設定するには：

powershell -NoProfile -ExecutionPolicy Bypass -File "$SkillRoot\scripts\install-model-instructions-file.ps1"

インストーラーは assets\system-prompt.md を $env:USERPROFILE\.codex\prompts\system-prompt.md にコピーし、以下のトップレベル TOML エントリを書き込みます。Python が利用可能な場合は TOML 構文を検証し、既存の config.toml のタイムスタンプ付きバックアップを記録します。

model_instructions_file = 'C:\Users\<user>\.codex\prompts\system-prompt.md'

メインラッパーと組み合わせるには、-InstallModelInstructionsFile を明示的に追加してください。

powershell -NoProfile -ExecutionPolicy Bypass -File "$SkillRoot\scripts\repatch-codex-windows.ps1" -InstallModelInstructionsFile

ファイルを変更せずに現在のマシンを検証するには：

powershell -NoProfile -ExecutionPolicy Bypass -File "$SkillRoot\scripts\install-model-instructions-file.ps1" -VerifyOnly

model_instructions_file を設定した後、新しいモデル指示ファイルが読み込まれるよう、Codex CLI/Desktop を再起動するか、新しいセッションを開始してください。

Computer Use のみ

MSIX を再パッケージ化せずに、ローカルの Computer Use プラグイン／ランタイムを修復する場合は、この方法を使用してください。ローカルの openai-bundled マーケットプレイスミラーを再構築し、ピン留めされたインストール済みパッケージソースを 1 つ使用して、安定版の computer-use／browser／chrome／sites キャッシュリンクを修復します。インストール済みの CUA @oai/sky ランタイムをローカルの Computer Use プラグインに重ねて適用し、必要に応じてローカライズされた値やデフォルト値に対応する Chrome レジストリ解析と Computer Use クライアントのインポート形式を修正します。稼働中の SKY_CUA_NATIVE_PIPE 設定を保持しながら古いオーバーライドを削除し、Chrome ネイティブメッセージングホストと 2 つの schema-2 app-server 状態ファイルを、現在の安定版キャッシュ／ランタイムパスに更新します。その後、クライアントのインポートまたは独立したランタイムトランスポートを検証します。

ランタイムが応答し、codex-computer-use-* パイプが存在し、-StrictVerifyOnly が成功するにもかかわらず、Object.keys(cua) にネイティブメンバーがない場合は、現在のプラグインのレイアウトを調べてください。以下のプラグインレベルの修復は、unified-computer-use/scripts/launch.mjs が存在する場合にのみ実行してください。descriptor-only の 26.908+ ビルドには、上記の対象を絞った ASAR ワークフローが必要です。

$surfaceRepair = "$SkillRoot\scripts\repair-cua-surface-lock.ps1"
powershell -NoProfile -ExecutionPolicy Bypass -File $surfaceRepair -VerifyOnly
powershell -NoProfile -ExecutionPolicy Bypass -File $surfaceRepair -Install

必須の対象が見つからない、サポートされていない、またはパッチが適用されていない場合、-VerifyOnly は失敗します。マーカーがあるだけでは、完全なパッチとして認められません。デフォルトのレポートと -Json のみの実行は読み取り専用です。-Json は、明示的なインストール／ロールバックレポートの形式指定にも使用できます。-VerifyOnly は書き込みモードと併用できません。-Rollback は、インストール済みパッチと一致する場合に限り、隣接する <file>.bak-* バックアップを復元し、それ以降の編集を上書きしないようにします。この修復では、キャッシュとサポート対象のマーケットプレイスソースのコピー全体で、scripts\launch.mjs 内の computer サーフェスを強制し、resources\computer-description.md に Windows 向けの説明を追加します。生成された .mcp.json は変更しません。新しいサーバーは、環境変数の値が browser のままでも、ランチャーから強制されたサーフェスを読み込みます。

このワークフローには、スクリプトベースのプラグインレイアウトが必要です。scripts\launch.mjs または必須の説明がない descriptor-only ビルドはサポート対象外です。チェックを通すためだけにプラグインを追加でインストールしたり、パッチの範囲を広げたりしないでください。scripts\test-cua-surface-lock-patterns.ps1 は、分離されたフィクスチャを使って修復をテストします。また、python "$SkillRoot\scripts\test-probe-cua-surface.py" は、サーバーを起動せずにプローブ結果の検証をチェックします。実際の probe-cua-surface.py では、説明、API メンバー、空でないウィンドウ／アプリケーションの結果が必要です。これは、実際に Desktop を再起動した証拠にも、スクリーンショットを取得した証拠にもなりません。 どちらのパッチも、同じバージョンの Desktop を再起動しても保持されます。リセットされるのは、プラグインキャッシュが再生成された場合のみです。通常これは、Desktop のアップグレードによってプラグインのバージョンディレクトリが移動した場合に発生します。Desktop の更新後は、再分析せずに再適用してください。-VerifyOnly を実行し、失敗した場合に限り -Install を実行します。このスクリプトはすべてのプラグインバージョンディレクトリを glob で検索するため、バージョンが上がっても編集は不要です。レポートに unsupported と表示された場合の対処については、references/restriction-debug-cases.md の再適用のケースを参照してください。

列挙は機能するものの、その後の Computer Use 呼び出しで node_repl exec context not found が返される場合は、修復する前にソースプロファイルを確認してください。

$contextPatcher = "$SkillRoot\scripts\patch-computer-use-node-repl-context.ps1"
powershell -NoProfile -ExecutionPolicy Bypass -File $contextPatcher

ドキュメントに記載されている @oai/sky 0.6.2 のプロファイルは、6423BA83...702B7C -> 3600AC24...5BB60A です。通常の install-computer-use-local.ps1 -VerifyOnly の手順でインストールしてから、現在の node_repl JavaScript カーネルをリセットし、-StrictVerifyOnly を再実行してください。パッチャーは元のファイルを .codex\backups\computer-use-node-repl-context にそのままバックアップし、-Rollback に対応しています。不明なハッシュは拒否します。エンドツーエンド検証では、1 回の JavaScript 呼び出しでヘルパーを起動し、その後の呼び出しで、制御された、あらためてアクティブ化したウィンドウをキャプチャする必要があります。これにより、テストでコンテキストの陳腐化が発生する境界を検証できます。

Windows 10 でネイティブヘルパーに到達しているものの、スクリーンショットのキャプチャ時に SetIsBorderRequired で 0x80004002 が発生する場合、または列挙が成功した後に FrameArrived timed out が報告される場合は、一般的なローカル修復を再実行する前にヘルパープロファイルを確認してください。

$helperPatcher = "$SkillRoot\scripts\patch-computer-use-helper-win10.ps1"
powershell -NoProfile -ExecutionPolicy Bypass -File $helperPatcher

ドキュメントに記載されている完全なヘルパー SHA-256 プロファイルのいずれかについて、結果が original-patchable の場合に限り、以降の評価が許可されます。実際に書き込みを行うには、Windows 10 であり、かつドキュメントに記載されたボーダーインターフェイスまたはフレームコールバックに関するスクリーンショットの失敗が発生している必要があります。Windows 11 でハッシュが一致しても、許可の根拠にはなりません。プロファイルには、古いボーダーインターフェイスのビルドと、issue #93 に記載された @oai/sky 0.7.6-F78948E6 および 0.7.6-63C98C4D までの新しいコールバックタイムアウトのビルドが含まれます。いずれもバイナリ、候補、アンワインドの検証は個別に行われていますが、Windows 10 でのキャプチャ／入力の受け入れ確認は保留中です。バイナリの互換性境界となるのは Desktop のバージョンではなくヘルパーのハッシュです。同じバージョンとして報告されていても、異なるバイナリが含まれている場合があります。

powershell -NoProfile -ExecutionPolicy Bypass -File $helperPatcher -Install

パッチャーは出力全体のハッシュを検証し、元のファイルを .codex\backups\computer-use-helper に保存して、-Rollback に対応しています。インストール後は、引き続き -VerifyOnly と -StrictVerifyOnly を実行してください。スクリーンショットの不具合が実際に解決されたことは、別途許可されたキャプチャテスト、またはユーザー提供のランタイム証拠で確認されるまで未検証です。このテストのために Explorer／Task Manager を自動的に開かないでください。不明なヘルパーハッシュにはこのプロファイルを適用しないでください。

ローカルの Windows Computer Use ファイルと環境ゲートのみを更新するには：

powershell -NoProfile -ExecutionPolicy Bypass -File "$SkillRoot\scripts\install-computer-use-local.ps1"

ローカルの Computer Use ファイルを検証し、不足があれば自動的に修復するには：

powershell -NoProfile -ExecutionPolicy Bypass -File "$SkillRoot\scripts\install-computer-use-local.ps1" -VerifyOnly

ファイルを変更せずに検証するには：

powershell -NoProfile -ExecutionPolicy Bypass -File "$SkillRoot\scripts\install-computer-use-local.ps1" -StrictVerifyOnly

キャッシュパスが見つからない、または古いことが原因で -StrictVerifyOnly が失敗した場合は、-VerifyOnly を 1 回実行してから、-StrictVerifyOnly を再実行してください。-VerifyOnly が成功しても Desktop がネイティブパイプを利用できないと報告する場合は、Codex Desktop を再起動し、最新の Desktop ログで computer-use native pipe startup ready を確認してください。

バックアップの管理

ローカルの Codex 設定、MCP サーバーエントリー、カスタムスキル、マーケットプレイス、Chrome ネイティブホストの状態をバックアップするには：

powershell -NoProfile -ExecutionPolicy Bypass -File "$SkillRoot\scripts\manage-codex-backups.ps1" -Action Backup

スナップショットを一覧表示または復元するには：

powershell -NoProfile -ExecutionPolicy Bypass -File "$SkillRoot\scripts\manage-codex-backups.ps1" -Action List
powershell -NoProfile -ExecutionPolicy Bypass -File "$SkillRoot\scripts\manage-codex-backups.ps1" -Action Restore -BackupPath "<backup path>"

成功の基準

• 既存の config.toml が変更された場合、ログには .codex\backups\config\ にタイムスタンプ付きのバックアップが表示されます。
• パッチログの selected Codex app と source package の行で、より新しい SYSTEM-Staged Store パッケージがある場合はそれも含め、対象となる最もバージョンの高いパッケージを確認できます。
• Get-AppxPackage -Name OpenAI.Codex で SignatureKind = Developer と表示されます。
• インストールログでは、パッチ適用済み Desktop パッケージを AppUserModelId 経由で起動し、WindowsApps での直接実行ファイルへのアクセス失敗を回避します。
• マニフェストで宣言された Codex Desktop プロセスは、インストール済みパッケージから起動され、実行を継続します。現在は新しいビルドでは ...\app\ChatGPT.exe、古いビルドでは ...\app\Codex.exe です。
• Fast Mode の検証では /v1/responses に到達し、request wire service_tier=priority がログに記録されます。/v1/models のプローブだけでは検証に合格しません。app-server のフォールバックを使用した場合は、thread/start serviceTier=priority もログに記録されます。
• パッチログには fast-mode UI patch result と locale i18n patch result が含まれ、それぞれ patched または already-patched になります。
• パッチログには custom models patch result が含まれ、パッチ適用済みのモデルフィルターに、設定済みのすべてのカスタムモデル ID が含まれます。
• パッチログには browser-use gate patch result が含まれ、patched または already-patched になります。
• Desktop ログには、パッチ適用済みアプリの起動後、available=true および reason=local-patched とともに browser_use_availability_resolved が表示されます。
• $env:USERPROFILE\.codex\config.toml に [marketplaces.openai-curated-local] が含まれます。
• $env:USERPROFILE\.codex\config.toml に [marketplaces.openai-bundled] が含まれ、install-computer-use-local.ps1 が選択したマーケットプレイスのルートを指します。また、そのマーケットプレイスにはインストール済みのバンドルプラグインとローカルの Computer Use オーバーレイが含まれます。codex-cli 0.149+ では openai-bundled は予約済みのマーケットプレイス名であるため、受け入れられるソースは Desktop が配置した予約済みルート .tmp\bundled-marketplaces\openai-bundled です。スクリプトがこのルートにフォールバックするのは正常な動作であり、構成のずれではありません。また、codex-cli refused the local bundled marketplace source; repointing marketplaces.openai-bundled at the reserved root とログに記録されます。安定した非予約ルートが想定されるのは、それを引き続き受け入れる古い CLI バージョンのみです。予約済みルートのソースを安定したルートに「修正」しないでください。修正すると CLI がマーケットプレイス全体を削除するため、codex plugin marketplace list --json に openai-bundled が表示されなくなり、Desktop ログに marketplace `openai-bundled` is reserved and cannot be added from this source と記録されます。.codex\.tmp が別のボリュームへのジャンクションである場合、予約済みルートを使用しても C ドライブを使わないという制約には違反しません。予約済みパスはそのボリュームに解決されるためです。
• 個人用プラグインで使用される設定済みのローカルマーケットプレイスには、サポート対象の .agents\plugins\marketplace.json が必要です。ルートレベルの marketplace.json だけでは、現在のプラグイン CLI には不十分です。
• codex plugin list に、要求された修復に必要なプラグインが installed, enabled として表示されます。Browser／Chrome／Computer Use の作業では、browser@openai-bundled、chrome@openai-bundled、computer-use@openai-bundled が含まれます。任意のプラグインは以前の状態を維持します。
• -VerifyAllBundledPluginsAvailable が要求された場合、安定した openai-bundled マーケットプレイス内の完全な各記述子は、インストール済みパッケージと同じ名前およびバージョンを持ち、既存のローカルソースがある CLI の installed と available の JSON エントリーの統合集合に、そのバージョンで表示されます。副作用として任意のプラグインがインストールまたは有効化されることはありません。このスイッチは、パッケージに含まれる独自の app\resources\plugins\openai-bundled マニフェストとマーケットプレイスを比較します。記録済みの 26.825.6671.0 のプラットフォーム／アカウントの不足は引き続き想定内ですが、サポート対象の 26.1007 における任意エントリーの検出修復では、デプロイ後に公開可能な 9 つすべての記述子が必要です。references/restriction-debug-cases.md にあるバンドル記述子の両方のケースを参照してください。不一致だけを理由に、未知のゲート上書きを許可してはなりません。
• 最近の Desktop ログには、現在のパッケージのバンドル記述子名が保持され、すでにインストールされているプラグインが not_in_bundled_marketplace_plugin_names によって削除されたことは示されません。
• $env:USERPROFILE\.codex\config.toml に、enabled = true を含む [plugins."computer-use@openai-bundled"] が含まれます。
• codex plugin list に computer-use@openai-bundled が installed, enabled として表示されます。
• Chrome／ブラウザーの使用が必要な場合、codex plugin list に chrome@openai-bundled と browser@openai-bundled が installed, enabled として表示され、Chrome のネイティブメッセージングホストのマニフェストは .tmp\bundled-marketplaces ではなく、安定した現行バージョンのキャッシュを指し、そのオリジンは現在の extension-ids.json と完全に一致します。extension-host.exe のディレクトリには、スキーマ 1、パッケージと一致する現在のユーザーローカル codex.exe、および同じランタイムの現行 node.exe／node_repl.exe パスを含む extension-host-config.json があります。%LOCALAPPDATA%\OpenAI\Codex\chrome-native-hosts-v2.json と $env:USERPROFILE\.codex\chrome-native-hosts-v2.json の両方に、同一の現行スキーマ 2 エントリー、公式の NUL 区切り SHA-256 ID、インストール済みパッケージの resourcesPath、および存在するランタイム／キャッシュのパスが含まれます。アクティブなマーケットプレイスとバージョン付きキャッシュの browser-client.mjs のハッシュは、インストール済みパッケージと一致します。旧式のビルドでは、そのハッシュがインストール済みの app.asar にも必要です。26.814 形式のビルドでは、代わりにネイティブホストの完全なパス要件と、両方の v2 状態ファイルにある同じルートの安定した browserClientPath／browserServicePath 値が必要です。setupBrowserRuntime() が成功し、agent.browsers.get("chrome") が Chrome 拡張機能バックエンドを返し、chrome\latest と browser\latest（存在する場合）が安定したバージョンディレクトリに解決されます。また、実際のスモークテストで Desktop のブラウザーチャネルを通じて指定された公開 HTTPS ページを読み込み、最終 URL、確認されたタイトル、有意な可視コンテンツを検証します。
• Chrome／ブラウザーのスモーク検証が対象範囲内で、Chrome が起動していない場合、追加のユーザー承認を求めずに Chrome を自動起動します。作業に関連する公開 HTTPS ページを使用し、最終 URL、確認されたタイトル、有意な AX／DOM コンテンツを検証します。過去の example.com の見出しのような固定のサードパーティー DOM は必須にしません。対象へのアクセスに失敗した場合やページが変更された場合は、references/restriction-debug-cases.md の「Browser Smoke Target Changes or Fails Independently」ケースを使用してください。
• CODEX_ELECTRON_ENABLE_WINDOWS_COMPUTER_USE が現在のユーザーに対して 1 に設定されています。
• 完全な再パッチでは互換性のために [features] computer_use = true を書き込む場合がありますが、対象を絞った -OnlyComputerUseSurface モードでは設定を編集しません。CLI 0.155.0-alpha.16.4 では、codex features list に computer_use が安定版で、既定で有効と表示されます。明示的なキーがなくても、新しい Desktop セッションでネイティブ CUA が利用可能で、ウィンドウ列挙に成功すれば、バックグラウンドチェックに合格します。キャプチャ／入力は独立した任意の証拠です。
• $env:USERPROFILE\.codex\config.toml に、sandbox = "unelevated" を含む [windows] があり、codex sandbox --help に表示されるサンドボックスコマンドの構文が正常に動作します。
• Computer Use プラグインのキャッシュは、インストール済みパッケージと一致します。従来の computer-use\latest\node_modules\@oai\sky と、現在の軽量なバージョン付きまたは記述子のみのキャッシュに加え、%LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node もサポートします。検証では、ヘルパートランスポートまたは公式の独立したランタイムエクスポートを通じて list_windows に到達します。
• scripts\install-computer-use-local.ps1 -StrictVerifyOnly は、従来のレイアウトでは client import ok と helper transport ok をログに記録し、記述子のみのレイアウトでは method=list_windows とともに runtime import ok をログに記録します。
• スクリプトベースの CUA サーフェスロックでは、scripts\repair-cua-surface-lock.ps1 -VerifyOnly により、検出されたすべてのコピーに完全な surface と description のパッチが適用されている必要があります。このテストを記述子のみの 26.908+ プラグインに対するゲートとして実行しないでください。記録済みの 26.903.61454 プロファイルでは、パッチ適用済みハッシュは 4312E22A...419175 と C72E08A0...FB9291 です。異なる完全なファイルについては、これらの過去のハッシュ接頭辞ではなく、そのファイル固有の証拠が必要です。両方のフィクスチャスイートに合格する必要があります。ライブプローブでは、Windows 向けガイダンス、3 つすべての API メンバー、n > 0 の windows/<n>、および強制された browser 環境下での正のアプリケーション数を報告する必要があります。実際の Desktop の再起動、承認 UI、スクリーンショットの結果は別々に記録してください。外部プローブではそれらを確認できません。
• Windows ネイティブ Computer Use はウィンドウ ID を使用します。@oai/cua 0.2.5 では、同梱の tinysky_alt コードとドキュメントに、Windows 向けの cua.listWindows()、cua.listApps()、cua.getApp({ windowId }) が公開されています。低レベルの cua.computer.* ウィンドウ API も利用できます。以前の Native app bindings are unavailable for windows. ケースが適用されるのは、記録済みの旧ランタイムのみであり、すべての Windows ビルドではありません。ランタイムのインポート成功やソースの調査は、ASAR ゲートを復元した後に新しい Desktop キャプチャを実施することの代わりにはなりません。
• サポート対象の @oai/sky 0.6.2 のクロスコール承認プロファイルでは、scripts\patch-computer-use-node-repl-context.ps1 は SHA-256 3600AC240CD6CB7029F1E489DF990CAE22D72177350B8084412DF1F3FA5BB60A で patched を報告し、元のバックアップは 6423BA834F18139D55CDAC2290C91CD9B24B568332B07CDDD2A7EDA043702B7C と一致します。
• 適用可能なパッケージ／ランタイム要件と実際のヘルパー列挙が、対象を起動またはアクティブ化したり入力を送信したりせずに満たされる場合、既定のネイティブ Computer Use 検証に合格します。ネイティブスクリーンショット／入力は未実施として記録してください。これらの任意チェックは、通常の修復を完了するために必要ありません。
• ユーザーがネイティブキャプチャ／入力の診断を明示的に許可した場合は、1 回の呼び出しで永続ヘルパーを起動し、その後の独立した呼び出しで合意した対象を操作します。スクリーンショットの内容を確認し、許可された各操作の効果を記録してください。スクリーンショットの枚数や PNG ファイルだけでは、キャプチャの証拠になりません。ユーザーが中断した場合は、対象を再度開いたりアクティブ化したりせず停止してください。
• 外部エグゼキューターで、既定の検証用に公式ランタイムの読み取り専用列挙を実行できます。外部プロセスによるキャプチャまたは入力には、Desktop の操作と同じ明示的な許可が必要です。これはその境界を回避する方法ではありません。そのテストが許可されている場合は、キャプチャと element_index 入力を 1 つのプロセス内で実行してください。Chrome／ブラウザーのスモーク検証では、引き続き Desktop の信頼されたブラウザーチャネルが必要です。環境の前提条件については references/restriction-debug-cases.md を参照してください。
• サポート対象の Windows 10 スクリーンショットヘルパープロファイルでは、scripts\patch-computer-use-helper-win10.ps1 は、選択したプロファイルの完全な出力 SHA-256 を示して patched を報告し、元のバックアップはプロファイルの完全な入力 SHA-256 と一致します。各ドキュメント化されたプロファイルには、静的キャプチャの反復チェックと動的キャプチャの画像変化チェックがあります。対応するペアは 0.4.20: F2B2F56F... -> 71A13CBC...、0.5.2: 2C4CAC16... -> D816B14A...、0.6.6: BE488E66... -> 34D6EB4F...、0.6.11: DE07F17A... -> 40530E62...、0.6.11: 7A95D14E... -> E84A4ECB...、0.6.16: E40BE614... -> F35CA6D8...、0.6.17: 29D5E113... -> DC83663F... です。1 つの @oai/sky バージョンに複数のヘルパーバイナリが含まれる場合があるため、プロファイルはバージョン文字列ではなく完全なハッシュで選択してください。0.6.6 のベースラインには、起動直後の Explorer キャプチャ、変化のない静止キャプチャ 10 回のバッチを 2 回、ウォームアップ後の 20 回のキャプチャでのリソース数、および Task Manager の異なるパフォーマンスフレーム 3 つが含まれます。0.6.16 のベースラインには、同一の静止フレーム 10 個、Performance タブの異なるフレーム 8 個、アクセシビリティテキスト、20 回のキャプチャによるリソース安定性サンプルが含まれます。0.6.17 のベースラインでは、同じ 5 つの保護領域を再利用し、固有の静止フレーム 8 個、固有の動的フレーム 20 個、およびスレッド／ハンドル／ワーキングセットの安定性サンプルを追加します。動的キャプチャチェックでは、対象をアクティブ化し、連続してアニメーションする表示を選択する必要があります。Task Manager の Processes タブがバックグラウンドにあると再描画されず、パッチとは無関係の理由でフレームが同一になるためです。また、対象は実際の実行ファイルが所有するブラウザー以外のウィンドウである必要があります。Computer Use はブラウザーウィンドウに対するターンを could not determine the current browser URL on Windows with enough confidence to enforce policy で終了します。また、list_windows は powershell.exe がホストするウィンドウを列挙しません。
• パッチ適用済み ASAR では、Computer Use の利用可能性ゲートとインストールゲートがローカル利用可能に強制されています。新しいビルドでは、これらの対象は古い use-is-plugins-enabled-* チャンクおよび use-plugin-install-flow-* チャンクではなく、webview\assets\app-initial-*.js に統合される場合があります。
• パッチ適用済み ASAR では、Fast Mode UI ゲートのブロックが解除され、ロケールチャンクで enable_i18n が強制的に有効化され、browser_use の機能チャンク／メイン機能ディスパッチがパッチされて、アプリ内および外部ブラウザーの利用可能性がローカルで報告されます。Codex Desktop 26.721.3996.0 では、Fast UI、モデルの表示、Browser サイドバーの対象を webview\assets\app-initial-*.js に統合できます。
• スマートフォンのリモートコントロール修復では、パッチ適用済み ASAR に remote_control_desktop_fetch_override_used、remote_control_auth_token_expired_skipped、remote_control_mobile_setup_no_auth_redirect、remote_control_mobile_setup_authorize_before_enable、remote_control_mfa_info_403_nonblocking、remote_control_client_list_partial_failure_nonblocking、remote_control_settings_force_control_this_pc_visible、remote_control_settings_force_remote_control_section_visible、remote_control_qm_start が含まれます。
• ネイティブ置換を伴うスマートフォンのリモートコントロール修復では、実行中の app\resources\codex.exe に remote_control_app_server_isolated_oauth_used、remote_control_native_remote_json_first、remote_control_websocket_proxy_attempt、remote_control_websocket_proxy_connected、remote-control-oauth.json、remote.json、codex.remote_control.enroll が含まれます。
• スマートフォンのリモートコントロールでデバイス一覧へのログインエラーが発生した場合、scripts\refresh-remote-control-auth.py --verify-only は /backend-api/wham/remote/control/clients に対して ok: true を報告します。スクリプトが認証情報を再生成した場合、以前の .codex\remote.json はバックアップされ、.codex\auth.json と config.toml は変更されません。
• スマートフォンのリモートコントロール修復では、Settings -> Connections にモバイル／電話のセットアップ経路が表示され、QR コードが表示されます。スマートフォンでのスキャン時に Codex 環境の期限切れが報告されなくなり、PID／パスと相関するネイティブログに remote_control_websocket_proxy_connected とステータス Connected が表示され、Windows の os error 10060 が繰り返し発生せず、スマートフォンから送信されたターンが Desktop に到達します。一部のネイティブバージョンでは Ping／Pong フレームがログに記録されないまま処理されるため、フレームテキストは任意です。スマートフォンから送信されたターンが誤ったモデル API エンドポイントを対象にする場合は、ペアリング後の設定ケースとして扱ってください。
• Dynamic Tools Schema の修復では、パッチ適用済み ASAR の webview\assets\app-server-dynamic-tools-*.js が、名前空間のラッパーオブジェクトではなく、namespace、name、description、inputSchema を含むフラットなエントリーを返します。そのアセットに対して node --check が成功し、Desktop で実際に新しいチャット／スレッドを作成しても、missing field inputSchema がログに記録されません。
• Provider History Sync では、App と旧式の SQLite ストアの両方で、現在のプロバイダーの下にスレッド行が報告され、読み取り可能なロールアウトの先頭行に現在のプロバイダーが示され、config.toml sha256 unchanged がログに記録され、公式 Desktop の会話が再表示され、新しい空のプロジェクトグループが作成されません。
• SDK のクリーンアップが有効になっていた場合、makeappx.exe と signtool.exe は再び見つからなくなります。