ChatGPT Dotsの承認ループとローカル連携の不具合報告
目次
ChatGPTのAIエージェント機能DotsにGitHubの作業を任せていると、同じ承認カードが延々と出る。
「常に許可」を選んだはずなのに、また確認が出て、そのたびに作業が止まる。
最初は変更をGitHubへ送るプッシュのときに出ているのかと思っていたが、画面には「Allow GitHub to create a Git blob?」と出ていた。
Gitの blob（ファイル内容を保存するオブジェクト）を作成してよいかの確認で、プッシュ前の段階だった（GitHubの説明）。
Dotsが返した設定の説明と訂正
Dotsに「なんで毎回聞くんだ」と尋ねたところ、GitHubの設定を確認したという返答があった。
設定を読み取ると、GitHubは現在「既定に従う」で、全体設定の「低リスク操作を許可」を継承していました。
その後、Dotsは承認カードの画像を確認したあとの返答で、説明を訂正した。
先ほど読んだアプリ全体の設定だけでは、このボタンの許可が保存されたかまでは分かりませんでした。
「設定が足りないから」と説明するのは誤りです。
現状、この確認ループをこちらから解消できていないのが問題です。
「Always allow」選択後も再承認が出る（Issue #52503）
OpenAIのCodexリポジトリには、Dotsで同じ承認が繰り返される不具合報告（Issue #52503）が投稿されていた。
報告者の環境はmacOSのSafariで、「Always allow」（常に許可）を何度選んでも再承認が出たと報告している。
過去の承認カードが「This request is no longer pending」（この要求はすでに保留中ではない）と表示されて操作不能になる状態や、ファイル内容をGitHubに登録する create_blob の操作で処理が止まる状況が記録されている。
このIssueと次の#52714はいずれも2026年10月9日に投稿され、10月15日時点でもオープンのままだ。
ファイルサイズによる承認判定の境界（Issue #52714）
#52714の報告者は、GitHub連携の操作許可を「Allow all actions」（すべての操作を許可）に設定し、ファイルの大きさを変えながら挙動を確認していた。
JSONの内容を保ったまま末尾の空白量を変える方法と、空白や改行を詰めて縮小する方法の2通りを試している。
| 試験 | ファイルサイズ | 承認カードの表示 |
|---|---|---|
| 末尾の空白量を調整 | 719,687バイト | 出なかった |
| 末尾の空白量を調整 | 720,000バイト | 出た |
| JSONの縮小前 | 874,365バイト | 出た |
| JSONの縮小後 | 645,251バイト | 出なかった |
報告者は719,687バイトと720,000バイトの間で、厳密に何バイトから承認が出るかまでは特定していない。
内部の判定理由や、ほかのGitHub操作でも同じ境界になるかは不明とされている。
また、Dotsの返答では全体の「低リスク操作を許可」を使っていたとのことで、この検証とは前提の許可設定が異なっていた。
限定的な回避例と設定変更の限界
「Allow all actions」に設定しても再発が報告されており、許可設定を広げても解決しなかった。
#52714で通っていたのは、JSONを縮小する方法や、小さな別ファイルとして先に登録したデータを参照して追加する方法だった。
同じ大きなファイルへの書き込みを2回に分ける方法では、2回目にファイル全体を送る処理になって再び承認が出ている。
Dotsの公式ドキュメントでは、接続済みアプリの権限はDotsにも適用されると書かれている。
操作ごとの自動審査もあり、指示、権限、カスタムルール、組み込みの安全要件から、実行可否や追加承認の要否を判定する。
カスタムルールでも組み込みの安全要件は上書きできない。今回のDotsの返答では、どの審査が再承認を求めたのかまでは分からなかった。
確実な回避策がないまま無人でGitHub作業を任せるなら、OpenAI側の修正を待つほかない。
アプリの更新で直るのか、サーバー側の修正が必要なのか、提供時期も含めて未公表だ。
GitHub連携を使わず、通常のGitコマンドで送信する方法もある。
ただし#52503では、クラウド作業環境でGitHub連携が使えても、Gitから送るための認証がなく失敗した例があった。
自分でプッシュや承認を引き受けるやり方では、最後までDotsに任せきりにはできない。
GitHub以外にも作業消失や接続切れの報告がある
公開Issueは各利用者の環境での報告であり、OpenAI側で原因が特定されたものや、全環境で再現する性質のものではない。
クラウド作業環境でのファイル消失報告（#52217）
10月8日の#52217では、Dotsのクラウド作業環境で、ソースや文書などが繰り返し見つからなくなったと報告されている。
保存済みのLibraryの成果物は残っていたが、作業中の内容は一部しか復元できなかった。
環境の入れ替えや保存領域の接続不良など原因は未確定だが、別に接続していたMac側の作業ファイルは残っていたと明記されている。
アーカイブしたローカルタスクの再開報告（#50338）
10月2日の#50338では、接続したMacで動くタスクをアーカイブしたあと、Dots経由の追加指示で処理が再開した。
実行中になってもアーカイブ済み一覧に残り、状態表示が食い違っていたという報告だ。
何も指示していないのに勝手に再開したわけではなく、アーカイブ中のタスクに指示が渡って実行された点が問題になっている。
切断後も実行中表示が残る報告（#54024）
10月14日の#54024では、クラウドタスクの切断が繰り返されても、状態が実行中のままで実際に処理が続いているか分からなかったと報告されている。
途中で成功した操作もあり、終日すべての処理が停止したわけではない。
接続したPCへのアクセス権限とWork・Codex連携
公式のタスク一覧では、接続したPC上で新しいWorkタスクやCodexタスクを作り、既存のローカルCodexタスクを続行できるとされている。
クラウドから進行を指示しながら、実行にはローカルPC上のファイルやツールを直接使う構成だ。
PCへの接続設定は、Dotsのプロフィールで「Computers」→「Your computer」→「Allow access」と進めて有効にする。
CodexへのPC接続やWork同期とは別の権限で、それらを有効にしてもDotsのPCアクセス権限は別個の設定になっている。
接続許可はタスク終了後も維持されるため、PCがオンラインでChatGPTアプリが起動していれば、スマートフォンなど別端末からの指示でもローカルPCが操作される。
ローカル作業ファイルの消失報告（#34698）
Dots固有の報告とは別に、7月22日の#34698では、Windows版Work・Codexでローカル作業ファイルが消えた事例が報告されている。
当時のアプリはバージョン26.715.8383.0で、ChatGPTプロジェクトの同期エラーと再起動のあと、管理下のフォルダーから生成済みHTMLやMarkdownが失われたとされている。
現在のDotsで再現が確認されたわけではないが、ローカル作業データが消えた報告がある以上、GitHub操作で承認が出るからといってPC側が保護されるわけではない。
書き込みやコマンド実行を許可した範囲では、誤操作や不具合でファイルを損なうおそれがある。
また企業向けの公式ドキュメントによると、クラウドから管理する処理は、PC上で実行する場合でもローカル設定のフック（コミット前などの自動チェック処理）が効かない。
手元の環境だけで動かすときのチェックが通らない点にも注意が必要だ。
停止操作とPC接続権限の取り消し
公式の停止方法は、Dots本体、委任先のタスク、定期実行で分かれている。
| 対象 | 操作 |
|---|---|
| Dots本体の現在の作業 | Pauseで一時停止 |
| 委任した個別タスク | Activityから開いて停止 |
| 今後の定期実行 | Scheduledで無効化・削除 |
| PCへの接続許可 | Revoke accessで取り消す |
Pauseを実行しても、委任先タスクや今後の定期実行までは止まらない。
またPCがオフラインになっても接続許可自体は維持されるため、アクセスを完全に遮断するにはRevoke accessから取り消す。
すでに実行された変更は停止操作では元に戻らないため、作業中タスク、委任先、定期実行、PC接続許可の各状態を個別に確認・停止する。
それはもはやDotsの意味ないよね。