ChatGPT Agent がローカルファイルを見られないのは、単に性能が低いからではありません。通常の入口は、アップロードしたファイル、Library、接続済みアプリ、データソース、または明示的に許可した GitHub リポジトリです。PC上の任意フォルダが自動でマウントされるわけではありません。
Codex local と Claude Code local は出発点が違います。どちらも選択したプロジェクト、作業ディレクトリ、またはローカルセッションから動くため、リポジトリ内のファイルを読んだり、差分を作ったり、テストを実行したりできます。ただし、そこにも sandbox、approval、write root、Bash ルール、allow/deny、bypass の境界があります。
2026年6月1日時点で見るべき核心は、どの agent が強いかではなく、どの画面がファイル経路を所有し、その後にどの権限を渡すかです。読み取りだけでよいのか、書き込み、コマンド、ネットワーク、GUI 操作まで必要なのかを分けてから許可します。
| ファイルの状態 | 適切な経路 | 最初にすること | 避けること | | PDFや表計算だけ | ChatGPT upload / Library | 必要なファイルだけ渡す | フォルダ全体を渡す | | ローカルrepoとテスト | Codex local / Claude Code local | 作業領域でdiffとコマンドを確認 | ChatGPTが未コミットを見えると思う | | push済みrepo | GitHub / cloud clone | branchを明示して渡す | 読み取り経路とコード変更を混同する | | secretsや.env | 脱秘匿fixture / 隔離環境 | denyと最小データを先に置く | 遠隔画面へ直接渡す |
短い答え：agent にはファイルへの経路が必要
ChatGPT Agent は ChatGPT の製品画面であり、現在のプロジェクトディレクトリに開いた shell ではありません。したがって、ファイルは upload、Library、connector、data source、GitHub authorization のどれかを通って初めて作業対象になります。
一枚の資料を読むだけなら upload が最短です。複数ファイルの実装、テスト、未コミット差分、依存関係、ローカルサービスが必要なら、Codex local または Claude Code local を選ぶ方が自然です。ファイル経路が違うため、同じ質問でも使う画面が変わります。
安全な順番は、実行場所を決める、ファイル経路を決める、読み取り・書き込み・コマンド・ネットワーク・GUI の権限を決める、の三段階です。この順番を飛ばすと、必要な一ファイルのために関係ない秘密情報まで見せることになります。
| 状態 | 推奨経路 | 理由 | | 単一文書 | ChatGPT upload | コピーだけで足りる | | テスト付きrepo | local coding agent | 実行環境が必要 | | 未コミット差分 | local agent | cloudは自動では知らない | | push済みbranch | GitHub/cloud | 明示的に渡せる | | secrets | fixture/isolated workspace | 漏えい面を先に減らす |
ChatGPT Agent の境界：アップロード、接続、認可
ChatGPT Agent は強力なツールを持ちますが、そのツールは ChatGPT の環境にあります。ブラウザ、表計算、ファイル処理、ターミナル風の操作があっても、それはあなたのローカル zsh や node_modules がある checkout とは別です。
そのため、タスクはデータ経路として指定します。契約書なら契約書だけをアップロードします。再利用する資料なら Library に置きます。クラウドサービスのデータなら connector を使います。GitHub 上のコードなら選択した repository を認可します。
ここで重要なのは最小化です。ChatGPT に見せる必要がない .env、顧客CSV、社内メモ、未公開コードは渡さない。ファイルを見せること自体が権限付与なので、読ませる内容を小さく保つ方が後の説明責任も軽くなります。
| ChatGPT経路 | 得意な用途 | 覚える境界 | | Upload | 文書、PDF、CSV、画像 | 見えるのはアップロードコピー | | Library | 再利用するファイル | ローカルディスク同期ではない | | Connectors | クラウドデータ | アカウントと組織設定に依存 | | GitHub app | 選択repo | 読む、探す、引用する経路であり、編集やpushはしない | | Agent tools | web作業 | 任意のhost filesystemではない |
リスク半径で並べる安全な回避策
「ChatGPT にローカルファイルを読ませる」話では、self-hosted MCP server、tunnel、watch folder、remote desktop、bridge script へすぐ進む説明が目立ちます。これらは用途によって有効ですが、最初の選択肢ではありません。安全な順番は、小さなデータコピーから始め、必要な時だけ live bridge に近づくことです。
| 回避策 | 使う場面 | リスク半径 | 停止ルール |
|---|---|---|---|
| Upload / Library | 特定ファイルを読む、要約する、抽出する、比較する | ファイルが小さく脱秘匿済みなら低い | secrets、顧客export、不要なフォルダが含まれるなら停止 |
| Connector / GitHub | 情報がクラウド app や選択repoにある | 中程度。アカウントと組織権限に依存 | 未push状態、local tests、コード編集が必要なら停止 |
| Codex local / Claude Code local | repo編集、test、生成物、local log、working tree が必要 | sandbox、write root、command、network 次第で中から高 | workspace 外へ広げる前、または secrets を出す前に停止 |
| Sandbox / manifest handoff | 必要ファイルだけの作業領域を作れる | mount、file、runtime config が狭ければ制御しやすい | manifest が home directory や secrets を引き込むなら停止 |
| Self-hosted MCP / tunnel / live bridge | bridgeを自分で管理し、狭いフォルダへの反復アクセスが必要 | 高い。遠隔の会話面が能動的なローカルデータ経路になる | folder-scoped、可能ならread-only、secret-free、log付き、使い捨てでなければ停止 |
| 手動の脱秘匿fixture | 実環境が敏感で、小さな例で再現できる | privacy では最も低いが準備は遅い | fixture が実問題を再現しなくなったら停止 |
OpenAI の sandbox manifest の考え方も同じ方向です。workspace を明示し、path は workspace-relative にし、mount は狭くし、secrets は prompt や artifact ではなく runtime config に分ける。ChatGPT Agent では、同じ発想を一つのファイル、脱秘匿ログ束、一つの connector、一つの選択repo、または隔離workspaceとして作ります。
高リスクなのは、便利だからという理由で自分のマシンを live bridge にすることです。MCP や tunnel を選ぶなら、使い捨て profile、狭いフォルダ、可能なら read-only、.env なし、SSH key なし、browser cookie store なし、ログあり、kill switch ありにしてください。そこまでの制御が重すぎるなら、upload、Library、GitHub read/search、または local coding agent の方が合っています。
Codex の境界：local、cloud、mobile control
Codex local はプロジェクトから始まります。app では folder を選択し、IDE agent は project directory を読み、CLI は current directory から動きます。このため ChatGPT Agent よりローカルファイルに近く見えます。
ただし、ローカル開始でも全権ではありません。sandbox mode、permission profile、writable root、network policy、approval policy が実際の動きを決めます。最初から danger-full-access にするのではなく、workspace 範囲で完了できるかを確認します。
Codex cloud は別の経路です。repository を隔離環境に clone して作業するため、push された branch には向いていますが、手元だけの変更は自動で見えません。mobile control もスマホ内ファイルの共有ではなく、接続された host や cloud task を操作する入口です。
| Codex形態 | ファイルの出所 | 確認点 | | Local app / IDE / CLI | 選択workspace | sandboxとapproval | | Cloud thread | cloneされたrepo | branchが状態を含むか | | Mobile | 接続host/cloud | スマホはcontroller | | Computer Use | 見えているUI | UIが証拠の時だけ |
Claude Code の境界：ローカル能力にもルールがある
Claude Code local は ChatGPT Agent より Codex local に近い存在です。ローカルの repository を読み、ファイルを編集し、Bash command を実行できるため、実装、テスト、リファクタリング、ログ確認に向きます。
しかし権限は rules と mode で決まります。read access、additional directories、deny rules、file modification prompt、Bash allow/ask/deny、defaultMode、acceptEdits、auto、dontAsk、bypassPermissions はそれぞれ別の意味を持ちます。
bypassPermissions は見えないファイルを解決する最初の手段ではありません。確認を減らすなら、その前に作業領域を使い捨てにし、秘密情報を除き、変更できる範囲を説明できるようにします。確認を飛ばすほど、外側の隔離が重要になります。
| 問い | Claude Codeの制御 | 実務上の意味 | | どのpathを読むか | read / additional dirs / deny | 読める範囲を調整 | | どのfileを変えるか | edit prompt / mode | diffで確認する | | どのcommandを走らせるか | Bash allow/ask/deny | テストも権限対象 | | 確認を飛ばすか | dontAsk / bypass | 隔離環境向け |
権限レイヤー比較：見えることと実行できることは違う
visibility は読めるかどうか、authority は読んだ後に何ができるかです。README を読むこと、支払いコードを書き換えること、shell command を実行すること、network に出ることは別の許可です。
ChatGPT Agent の書き込みは生成ファイルや connector action として起きます。Codex local は workspace write と approval に従います。Claude Code local は edit prompt、mode、Bash rule に従います。GUI control はさらに別軸です。
良い許可文は実行前に言えます。この agent は現在repoだけを読み、src/ と tests だけを変更し、network command は確認し、.env を見つけたら止まる。これが言えないなら、まだ権限を広げる段階ではありません。
| 層 | ChatGPT Agent | Codex local | Claude Code local | | 発見 | upload/Library/connector/GitHub | workspace/current dir | session/rules | | 書き込み | generated output/action | workspace write/approval | edit mode/prompt | | commands | product tool | local shell under sandbox | Bash rules | | network | connected service | profile/approval | tool environment | | escalation | more data connection | profile/sandbox change | mode/bypass |
五つのファイル状態と最初の一手
同じローカルファイルでも状態が違えば経路も違います。デスクトップ上のPDF、テスト付きrepo、未コミット差分、push済みbranch、secrets入り設定は同じ扱いにできません。
単一文書は ChatGPT upload。repo は local agent。未コミット差分は local に残すか、意図して branch に push。push済みrepoは GitHub/cloud route。secrets は redacted fixture または isolated workspace。これだけで判断の大半は決まります。
迷ったら、まず小さいfixtureを作ります。秘密情報を消し、期待結果を書き、agent には read-only で分析させます。必要が明確になった後で、write や command を広げます。
- 文書: 必要なファイルだけ upload。
- repo: workspace内で diff と test を見る。
- 未push: cloud が見えない前提で扱う。
- GitHub: repo と branch を明示する。
- secrets: deny、脱秘匿、隔離を先に置く。
ファイル修復に見える危険な近道
danger-full-access や bypassPermissions は便利ですが、ファイル経路の説明にはなりません。どの画面がどのファイルを所有するのかを決めずに全権化すると、必要な一ファイルのために不要な権限まで渡すことになります。
広い権限が許されるのは、使い捨て clone、container、scratch VM、テスト用アカウントなど、外側の隔離がすでに強い時です。普段のPC、ログイン済みブラウザ、秘密鍵、顧客データが近くにある状態では最初の選択肢にしません。
Computer Use も同じです。設定画面、ブラウザフロー、デスクトップapp、GUI bug のように UI が証拠なら有効です。普通のファイルやrepoを読むだけなら、構造化されたfile routeやcommand routeを優先します。
| 近道 | 使える場面 | 止める場面 | | danger-full-access | 使い捨てworkspace | 主PCとsecrets | | bypassPermissions | 隔離済み環境 | 確認を減らしたいだけ | | folder upload | 脱秘匿bundle | 私物や秘密が混ざる | | GUI control | UIが証拠 | 通常のfile read |
実行前のローカル判断チェック
開始前に、単一ファイルかrepoか、テストが必要か、未コミット差分があるか、credentials が必要か、shell command が必要か、network が必要か、GUI を見る必要があるかを確認します。答えが経路を決めます。
内容理解だけなら ChatGPT upload が軽い。コード変更なら Codex local または Claude Code local。remote review なら clean branch を push。production secrets が近いなら先に isolated workspace。順番を守るだけで事故の多くは避けられます。
目的は agent に多くを見せることではなく、必要なものだけを見せ、必要な権限だけを渡すことです。小さな権限で強い agent を動かす方が、後で検証しやすく、差分も戻しやすくなります。
| 確認 | yesなら | 行動 | | single file | yes | upload / Library | | tests required | yes | local coding agent | | uncommitted diff | yes | local or push branch | | secrets nearby | yes | redact / deny / isolate | | GUI evidence | yes | narrow Computer Use |
権限判断を引き継ぎ可能な記録にする
実務で危ないのは、agent がファイルを見られないことだけではありません。後から誰も、agent が何を見て、どこで動き、どの操作まで許されたのかを説明できないことです。権限判断は、ファイル経路、実行場所、許可した操作、停止条件の四つに分けて記録します。これで uploaded copy、GitHub branch、Codex local workspace、Claude Code session、cloud clone を混同しにくくなります。
ChatGPT 経路では、渡した材料を具体的に書きます。脱秘匿したログとPDFだけを upload したなら、agent がプロジェクト全体を見たような依頼文にしません。GitHub app を使ったなら、repo、branch、未push差分は含まれないことを書きます。ChatGPT は入力が明確な反面、terminal や browser の存在でローカル権限があるように見えやすいため、ローカルpathと渡したコピーを分けて扱います。
Codex local では、workspace、sandbox、permission profile、write範囲、network、実行済み command、approval が必要な command を残します。コード修正では、この記録が diff と test output の説明になります。Codex cloud を使う場合は、どの branch を clone したか、手元だけの生成物や未コミット差分が入っていないかを別に確認します。
Claude Code では、mode と rules を明記します。auto、dontAsk、bypassPermissions を使うなら、使い捨て checkout、実 .env の除外、deny pattern、test account などの隔離条件が必要です。確認を減らすほど、外側の隔離が強くなければなりません。そうでない bypass は、見えないファイルの問題を監査できない操作に変えるだけです。
この記録は長文である必要はありません。別の担当者が、なぜ upload では足りないのか、なぜ local agent が必要なのか、なぜ network を許可または禁止したのか、どのディレクトリで止まるのかを理解できれば十分です。実行前に言語化できない時は、sample を小さくし、read-only 分析から始め、必要になってから書き込みや command を広げます。
| 記録項目 | 書く内容 | 避ける混同 | | ファイル経路 | upload、Library、GitHub、workspace、GUI | ローカル全体が見えるという誤解 | | 実行場所 | ChatGPT製品環境、local shell、cloud clone、接続host | local state と cloud state の混同 | | 許可操作 | read、write、command、network、GUI | 読めることを全権とみなす誤り | | 停止条件 | .env、secrets、顧客データ、未公開diff | 便利さのための過剰権限 |
よくある質問
ChatGPT Agent に terminal があるのに、なぜローカルフォルダを読めないのですか？
その terminal は ChatGPT 製品環境のものだからです。現在のPCで開いている shell ではありません。ファイルは upload、Library、connector、GitHub などの経路で渡す必要があります。
ChatGPT Agent は repo 全体を扱えますか？
GitHub などの対応経路で渡せば扱えます。ただし ChatGPT の GitHub 経路は、選択repoを読む、検索する、引用するためのものです。編集、削除、作成、push、PR作成の経路ではありません。未コミット差分、ローカルテスト、生成物、private env、コード変更が重要なら Codex local または Claude Code local が適しています。
Self-hosted MCP server は安全な回避策ですか？
狭く設計された bridge なら選択肢になります。ただし MCP、tunnel、watch folder は upload、Library、GitHub read/search、local coding agent よりリスクが高い経路です。フォルダを限定し、可能なら read-only にし、secrets を置かず、ログを残し、すぐ止められる状態にします。ひとつのファイルのために home directory や production checkout を開かないでください。
Codex local はローカルだから安全ですか？
自動的に安全ではありません。安全性は sandbox、permission profile、approval、writable root、network policy、そして作業環境の隔離で決まります。
Codex mobile はスマホ内のファイルを見ますか？
基本的には controller と考えます。ファイルや credentials は接続先 host または cloud task にあり、スマホ内ファイルは別の経路で渡す必要があります。
Claude Code の bypassPermissions は何でも見える設定ですか？
いいえ。通常の確認を飛ばす高信頼モードであり、隔離された作業領域で使うべきです。ファイル経路の説明にはなりません。
.env はどう扱うべきですか？
ChatGPT にアップロードしないでください。local agent では deny rule、脱秘匿fixture、秘密値を表示しない確認コマンドを使います。
Computer Use はいつ使いますか？
表示されているUIが証拠の時です。設定画面、ブラウザ操作、デスクトップapp、GUI bug などです。通常のファイル読み取りには使いません。