Codex Computer Useが許可後も動かないときの原因と対処手順

Codex Computer Useが許可後も動かない場合は、まずエラー全文を保存し、サイト・アプリ・シェルコマンドのどこで失敗したかを確認します。 ブラウザ接続の問題なら、許可済みの同じ小さな操作を新しいチャットで試し、必要に応じてブラウザやデスクトップアプリを再起動します。許可を何度も追加する前に、接続先とプラグインの状態を確認してください。

対象はCodexとChatGPT Workのデスクトップ環境です。「GPT computer use 権限」で見つかる、自作のComputer Use API実行環境の解説とは対象が異なります。

資料の確認日は2026年9月21日です。公式資料、GitHubの原報告、利用者の投稿を参照していますが、引用した障害を独自に再現したわけではありません。ある環境で復旧した方法が、すべての環境の原因や修正版を示すとは限りません。

最初にエラーが出る段階を確認する

これは原因を断定する表ではなく、調査の入口です。再起動後に「接続不可」が個別操作の承認に変わったなら、別の段階まで進んだ可能性があります。

「常に許可」だけでは足りない理由

公式Computer Useガイドでは、OSの権限、アプリへの許可、ファイルやコマンドを扱うサンドボックスを区別しています。macOSでは画面収録がアプリの表示を読むために、アクセシビリティが操作のために必要です。Windowsでは対象アプリがアクティブなデスクトップに表示されている必要があります。Computer Useプラグインのサーバーとスキルが有効かどうかも確認します。

サイトへのアクセス設定は別です。内蔵ブラウザは通常のブラウザとは別のプロファイルを使うため、Chromeにログイン済みでも同じログイン状態にはなりません。公式ブラウザ資料で接続方式を確認できます。

組織の管理対象端末では、ローカルの許可設定で管理者の拒否ルールを解除できません。許可ルールを追加しても、プラグインのインストールやOS権限の付与を代行するわけではありません。リダイレクト後のプロトコル、ホスト、ポートを確認し、サブドメインも一律に許可されるとは考えないでください。管理設定の説明が参考になります。

手順1：新しいチャットと元の会話を比較する

公式の拡張機能トラブルシューティングは、会話固有の接続状態をクリアするために、新しいチャットを試すよう案内しています。ブラウザは接続済みに見えるのに、特定のタスクだけ失敗する場合の確認に使えます。

切り替える前に、完了した作業、残りの作業、許可済みのアクセス先、エラー全文を短くまとめ、元の会話を残します。新しいローカルチャットで同じブラウザを選び、次のような読み取り専用の操作を依頼します。

選択したブラウザで、[明示的に許可した公開ページの正確なURL]を開き、ページタイトルを報告してください。
ログイン、アップロード、フォーム送信、内容の変更はしないでください。
失敗したらツールのエラー全文を報告し、そこで停止してください。

これは確認用プロンプトの例であり、実測結果ではありません。意図してアクセスを拒否した場合は、本人または管理者が通常の設定で判断を変更してから試します。新しいチャットを拒否の回避に使ってはいけません。

9月13日のGitHub報告 #45237では、全体設定で許可したサイトが会話固有の記録によって拒否され、新しい会話で復旧したと報告されています。報告者によると、確認画面が見えないまま拒否されたように見えたとのことです。確認時点でissueは未解決の状態で、内部の仕組みに関する説明は報告者の分析です。自分の端末も同じ原因だと断定はできません。

新しいチャットだけ成功するなら、会話固有の状態を調べる手掛かりになります。ただし、それだけで権限ファイルの破損が証明されるわけではありません。

手順2：接続できないコンポーネントから再起動する

まずデスクトップアプリの更新を確認します。ChatGPTやCodexを複数インストールしている場合は、実行中のものを特定し、使い続ける各インストールを更新します。未保存の作業を保存し、進行中の操作を停止してから、一つずつ試してください。

1. 外部ブラウザの接続なら、そのブラウザを完全に終了して開き直します。
2. 選択したプロファイルで拡張機能が有効か確認します。
3. 改善しなければChatGPT/Codexデスクトップアプリを完全に終了し、開き直します。ウィンドウを閉じるだけでは終了しない場合があります。
4. ブラウザの選択を確認し、同じ読み取り専用操作を再試行します。

公式の確認項目をもとに、変化を比較しやすい順序に整理しています。PC全体の再起動は、通常のアプリ再起動でも起動障害が残る場合の後続手段です。権限変更のたびに必要なわけではありません。

アプリの再起動と新しいチャットは別の確認です。再起動後に元の会話を開く場合と、新しい会話を作る場合を分けて記録します。

手順3：プラグインと拡張機能の接続を確認する

デスクトップアプリのSettings → Computer Useで選択中のブラウザを確認します。現在の公式資料では、接続済みの状態にManage、セットアップが必要な状態にInstallを使っています。ブラウザの切り替えスイッチはメンションメニューへの表示を制御し、サイトのアクセス許可とは別です。

Computer Useプラグイン自体も確認します。使用中のバージョンに無効化・有効化・再読み込みの操作があれば、通常のUIから実行して状態が落ち着くのを待ち、再試行します。復旧しても、特定のキャッシュ障害が証明されたとは扱いません。

拡張機能がまだ接続できない場合、公式資料はデスクトップ設定からの拡張機能の再インストールを案内しています。拡張機能、デスクトップアプリ、Codexのデータ保存先は別物です。どれを変更したか記録してください。別のクライアント向けの内部リセットコマンドを、そのままCodexに持ち込まないようにします。

手順4：OSごとの確認に進む

macOS：画面を読む権限と操作する権限を分ける

システム設定 → プライバシーとセキュリティで、画面収録とアクセシビリティの該当項目を確認します。Codex Computer Useの表示名はインストールしたバージョンによって異なる場合があります。終了と再起動を求められたら、その案内に従います。

切り分けには、手動で計算機を開き、Computer Useに表示内容だけを読み取らせる方法があります。これが成功し、ブラウザだけ失敗するならブラウザ接続を調べます。両方失敗しても、直ちにOS権限が原因と決めず、双方のエラーを残してください。この手順は診断の提案であり、引用した障害をMacで独自に再現したものではありません。

Windows：対象ウィンドウと補助プロセスの起動を分ける

ロックされていないアクティブなデスクトップ上に対象アプリを表示します。最小化されたウィンドウが見えないことと、補助プロセスが起動しないことは異なります。

#37415は通常のアプリ操作に入る前のspawn EPERMを扱っています。ある追記では、デスクトップアプリのビルド26.803.10989.0とプラグイン26.803.81509の組み合わせで、管理された権限のもと実行環境をリセットした後に復旧したと報告されています。ほかの報告とは結果が異なり、旧版への変更やサンドボックス無効化を勧める根拠にはなりません。

#25220では、WindowsAppsのコピー・インストールエラーと同梱プラグインの利用不可が報告されています。Storeのインストール先ドライブを変えた場合を含め、再インストールの結果は一致していません。

app-serverのエラーならWindowsのアプリサーバー起動ガイド、リソースの読み込みエラーならリソース読み込みの確認手順を参照してください。

復旧をどう確認するか

失敗した操作が保存・送信・公開を伴う場合は、再試行前に実際の状態を確認します。応答がないだけでは、操作が実行されなかったと判断できません。接続中断についてはstream disconnectedのトラブルシューティングも参照できます。

改善しない場合はリセットを繰り返さず、OSのバージョン、アプリのビルド番号、プラグインのバージョン、エラー全文、対象の種類、新旧会話の比較結果をアプリのフィードバックから報告します。公式トラブルシューティングにログの場所と会話共有の説明があります。共有前に秘密情報や私的な内容を取り除いてください。

よくある質問

GPTモデルを変えれば直りますか？

今回確認した資料からは、そのようには判断できません。プラグインの起動やブラウザ接続は、モデルが操作を選ぶ段階とは異なります。

Full accessにすべきですか？

標準の対処としては勧めません。まず失敗した権限やコンポーネントを特定します。ファイルやコマンドの権限を広げても、OS権限や接続が直った証拠にはなりません。

Ofox APIで権限の問題を直せますか？

その根拠はありません。モデルAPIへの接続とデスクトップアプリの権限・接続状態は別の問題です。

.codexを削除してやり直してもよいですか？

公式資料によると、会話記録は標準でこのディレクトリ内に保存されます。広範なリセットは保存状態に影響するため、まず証拠を残し、サポートの案内に沿った限定的な復旧を優先します。