ChatGPT Agent 看不到本地文件，不是因为它“能力不够”，而是因为它默认并不运行在你的当前电脑文件夹里。它能处理你上传、放入 Library、通过连接器授权或通过 GitHub 路线交给它的内容，但这和把整个桌面目录挂载给 agent 是两回事。
Codex 本地和 Claude Code 本地的出发点不同。它们通常从你选中的项目、仓库或终端会话开始，所以会显得更像“能看到本地文件”。但这也不是无限权限：Codex 还有 read-only、workspace-write、danger-full-access、网络和审批策略；Claude Code 也有读取、编辑、Bash、allow/ask/deny、模式和敏感文件规则。
截至 2026 年 5 月 23 日，最稳的判断不是问“哪个 agent 更强”，而是先问三个问题：文件现在在哪个界面里，agent 通过什么路线拿到它，接下来要允许读取、写入、执行命令、联网还是操作图形界面。只要这三个问题没回答清楚，就不要为了省事直接开全权限。
| 场景 | 正确入口 | 先做什么 | 不要做什么 | | 一份文档、CSV 或 PDF | ChatGPT 上传或 Library | 只交给它当前任务需要的文件 | 不要上传整个文件夹和无关隐私 | | 本地仓库和测试 | Codex 本地或 Claude Code 本地 | 在当前工作区里读 diff、跑命令、看输出 | 不要期待 ChatGPT 自动看到未提交文件 | | 已推送 GitHub 仓库 | ChatGPT GitHub、Codex 云端或 Claude Code Web | 授权具体仓库和分支 | 不要把本地未提交状态当成云端可见 | | secrets、.env、客户数据 | 本地隔离工作区或脱敏样本 | 先设 deny 规则和最小 fixture | 不要直接给远程界面 |
快速答案：先判断谁拥有文件路径
ChatGPT Agent 的文件入口是产品路线，不是你当前 Mac 或 Windows 的 shell。上传文件、Library、连接器、授权 GitHub、表格工具和 Agent 浏览器都可以成为入口，但每条入口看到的是被交付后的副本、云端资源或被授权的仓库，而不是你的任意本地路径。
Codex 本地和 Claude Code 本地适合 repo 任务，因为它们从选定工作区出发。一个任务如果依赖本地测试、未提交改动、生成物、脚本、依赖缓存或本地服务，通常应该留在本地 agent 里处理；如果只是读一份报告或表格，上传到 ChatGPT 反而更简单。
这个判断顺序能减少误授权。先选界面，再选文件路线，再选权限层。权限不是“越大越快”，而是要和任务需要的读取、写入、命令、网络和 GUI 操作一一对应。尤其当目录里有 .env、私钥、客户导出或未发布业务数据时，文件可见性本身就是风险。
| 文件状态 | 推荐路线 | 理由 | | 单个文档 | ChatGPT 上传 / Library | 内容分析不需要本地执行环境 | | 多文件仓库 | Codex 本地 / Claude Code 本地 | 需要读代码、跑测试和看 diff | | 未提交改动 | 本地 agent | 云端无法自动知道私有工作树 | | 已推送仓库 | GitHub 授权或云端克隆 | 仓库可以被明确交给远程环境 | | 敏感配置 | 脱敏样本或隔离本地环境 | 先控制泄露面，再谈 agent 能力 |
ChatGPT Agent 边界：上传、连接或授权
ChatGPT Agent 可以使用工具，但它的工具运行在 ChatGPT 产品环境里。即使界面里有终端、浏览器或表格能力，也不能推出“它正在你的项目目录里”。它只知道当前对话、上传文件、Library 文件、连接器数据、被授权的 GitHub 仓库，以及工具执行期间能访问的资源。
所以要把任务说成文件路线。读合同就上传合同；分析日志就上传脱敏日志；复用材料就放入 Library；查云端数据就连接相应 app；查看已推送代码就走 GitHub 授权。每次只交出当前任务需要的最小材料，避免把整个桌面或整个仓库打包给远程界面。
最容易误解的是“Agent 有终端”。产品环境里的终端不是你的本地 zsh，也不是已安装项目依赖的 shell。它可以帮你处理被交付进去的数据，但不能自动读取 /Users/.../Projects/...。如果任务要求修改真实 checkout 并跑本地测试，路线应切回 Codex 或 Claude Code 本地。
| ChatGPT 路线 | 适合什么 | 边界 | | 上传文件 | PDF、表格、图片、日志包 | 看到的是上传副本 | | Library | 复用此前上传或生成的文件 | 不是本地磁盘镜像 | | 连接器 | 云端 app 或数据源 | 受账号、区域、工作区和授权限制 | | GitHub app | 被选择的仓库 | 看不到未提交本地改动 | | Agent 浏览器/工具 | 网页任务和产品内操作 | 不是任意主机文件系统权限 |
Codex 边界：本地线程、云端线程和手机控制
Codex 不是单一权限模型。桌面 app 的 Local 模式从本机项目文件夹开始，IDE agent 能读取项目、运行命令和写入改动，CLI 则从当前目录进入任务。这解释了为什么 Codex 本地比 ChatGPT Agent 更像能“看见文件”。文件路径本来就在它的执行上下文里。
但本地上下文不等于全机通行证。Codex 的 sandbox 和 permission profile 会决定能不能写 workspace、能不能联网、是否需要审批、是否进入 danger-full-access。正确做法是先用工作区范围完成任务，只有在能说明风险半径时才扩大读写或网络权限。
Codex 云端又是另一条路。云端线程通常克隆仓库，适合已推送代码、PR、隔离环境和可以远程复现的工作。手机控制也不是手机文件自动进入 Codex，而是手机作为控制器连接到主机或云端任务。文件、凭据和本地安装仍属于执行主机。
| Codex 形态 | 文件从哪里来 | 安全判断 | | Local app / IDE / CLI | 选定项目或当前目录 | 先用 workspace 范围和审批策略 | | Cloud thread | 被克隆或授权的仓库 | 不要假设能看到未提交文件 | | Mobile control | 连接的主机或云端状态 | 手机只是控制入口 | | Computer Use | 可见 GUI 状态 | 界面是证据时使用，不当普通文件读取 |
Claude Code 边界：本地仓库能力仍然要受规则约束
Claude Code 本地更接近 Codex 本地，而不是 ChatGPT Agent。它在本地仓库或终端会话中读代码、改文件、运行命令，因此适合需要真实 checkout 的开发任务。区别在于 Claude Code 的权限系统更强调工具、模式、规则和提示确认。
可读路径、可编辑文件、Bash 命令、additional directories、deny 规则、默认模式、accept edits、auto、dontAsk 和 bypassPermissions 都会影响实际行为。一个本地 Claude Code 会话能做很多事，但每一步仍要回答：它读的是哪个路径，改的是哪个文件，跑的是什么命令，是否跳过了确认。
如果任务周围有 .env、SSH 私钥、客户导出、账单文件或本地数据库 dump，不要用 bypassPermissions 解决可见性。更稳的是复制一个最小 fixture，或者把敏感目录写进 deny 规则，或者在一次性工作区里运行。权限越宽，隔离环境越应该强。
| 问题 | Claude Code 控制点 | 结果 | | 能读哪个路径 | read rules / additionalDirectories / deny | 本地访问可以缩小或扩大 | | 能改哪个文件 | 编辑确认和模式 | diff 仍是安全边界 | | 能跑什么命令 | Bash allow/ask/deny | 测试和脚本需要命令级信任 | | 能否跳过确认 | dontAsk / bypassPermissions | 只适合已隔离高信任环境 |
权限层比较：可见性不是执行权
可见性回答“agent 能不能读到这份内容”，执行权回答“读到以后能做什么”。很多事故来自把两者混成一句“让它看见我的文件”。看见 README 和能改支付代码不是同一个权限；能读取日志和能执行清库命令也不是同一个风险。
ChatGPT Agent 的写入多发生在生成文件、表格或连接器动作里；Codex 本地的写入受 sandbox、writable root 和审批影响；Claude Code 的写入受模式、编辑确认和 deny 规则影响。命令、网络和 GUI 控制也各自有独立边界，不能用一个“本地/云端”标签概括。
一个好的权限说明应该能在运行前说清楚：这个 agent 只能读当前仓库，不能读上级目录，能修改 src/ 和测试文件，联网要问，遇到 .env 要停止。只要你说不出这句话，就说明任务还没有拆到可授权的程度。
| 层级 | ChatGPT Agent | Codex 本地 | Claude Code 本地 | | 文件发现 | 上传、Library、连接器、GitHub | 项目目录、当前目录、配置根 | 本地会话、additional dirs、规则 | | 写入 | 生成物或连接器动作 | workspace 写入和审批 | 编辑确认、模式和规则 | | 命令 | 产品工具环境 | 本地 shell + sandbox | Bash allow/ask/deny | | 网络 | 产品工具和连接服务 | profile 与审批 | 工具权限和环境 | | 升级 | 连接更多数据 | 改 profile 或 sandbox | 改模式或 bypass |
五类文件状态和第一步
文件不是只有“本地”一种状态。桌面上的一个 PDF、仓库里的多个文件、未提交 diff、已推送 GitHub 仓库和带 secrets 的配置文件，都应该走不同路线。先判断状态，权限选择会清楚很多。
单个文档适合上传；多文件仓库适合本地 agent；未提交改动要留在本地或主动推分支；已推送仓库可以授权远程；敏感配置应该用脱敏 fixture 或一次性环境。这个顺序比“哪个工具最强”更可靠。
如果你不确定，先做最小复现：复制一份不含 secrets 的样本，写出期望输出，让 agent 只读分析。等判断明确后，再把真正的仓库、命令和写权限交给合适界面。这样慢半分钟，但能避免把错误环境交给强权限 agent。
- 文档类：上传必要文件，不上传整个目录。
- 仓库类：用本地工作区，保留 diff 和测试证据。
- 未提交改动：远程工具看不到，除非你主动推送或打包。
- 已推送仓库：授权具体 repo、branch 和任务范围。
- 敏感文件：默认不上传，先脱敏或隔离。
看起来像文件修复的危险捷径
danger-full-access、bypassPermissions、全磁盘访问和宽 GUI 控制都可能是正确工具，但不应该作为第一反应。它们解决的是审批摩擦，不是路线判断。如果 agent 连文件应该通过哪条路进入都没说清，开全权限只会把错误扩大。
可以使用宽权限的典型场景是一次性 clone、容器、临时 VM、无真实凭据的测试账号，或者已经明确限制外部影响的自动化环境。主力笔记本、真实客户数据、未提交商业代码和常用浏览器登录态都不是默认安全环境。
Computer Use 也要克制。界面本身是证据时，比如浏览器设置、桌面 app、支付页面、模拟器或 GUI bug，它很有用。但普通文件读取应优先走文件、仓库、命令或连接器路线。不要用可见桌面来弥补一个本该通过结构化文件完成的任务。
| 捷径 | 什么时候可能合理 | 什么时候应该停止 | | danger-full-access | 一次性隔离工作区 | 主力机器和真实 secrets | | bypassPermissions | 已隔离且任务边界清楚 | 只是为了少点确认框 | | 全目录上传 | 已脱敏资料包 | 目录混有隐私和无关文件 | | GUI 控制 | 界面状态就是证据 | 只是想读普通文件 |
本地决策清单
开始任务前，用这张清单压住冲动：文件是否能通过上传解决？是否依赖本地测试？是否含未提交改动？是否有 secrets？是否需要执行命令？是否需要联网？是否必须看 GUI？每个问题都对应不同路线。
如果只需理解内容，ChatGPT 的上传路线最轻。如果需要修改仓库并证明结果，Codex 本地或 Claude Code 本地更合适。如果要远程协作或 PR 审查，先推干净分支再给云端。任务一旦涉及生产凭据，就先隔离环境再授权。
最终目标不是让 agent 看见更多，而是让它只看见足够完成任务的东西。强 agent 加上小权限，通常比弱边界加全权限更稳定；一个能复述权限边界的任务，也更容易被审查、回滚和交接。
| 判断 | 如果是 | 推荐动作 | | 内容是否单文件 | 是 | 上传或 Library | | 是否需要测试命令 | 是 | 本地 coding agent | | 是否有未提交 diff | 是 | 留本地或主动推分支 | | 是否含 secrets | 是 | 脱敏、deny、隔离 | | 是否要看 GUI | 是 | 只给必要窗口和步骤 |
把权限决定写成可交接记录
实际协作里，最危险的不是 agent 没看见文件，而是团队没人知道它到底看见了什么。一次合理的授权记录应该写清四件事：文件从哪里进入，agent 在哪个主机或产品界面执行，允许它做哪些动作，以及遇到什么内容必须停下。这样即使换人接手，也能判断这是上传副本、GitHub 分支、Codex 本地工作区，还是 Claude Code 会话里的真实文件。
ChatGPT 路线的记录重点是“交付了哪些材料”。例如只上传 billing-sample.csv 和脱敏截图，就不要在需求里暗示它可以读取完整财务目录；如果用了 GitHub app，就写明仓库、分支、可见范围和未提交改动不在其中。ChatGPT 的好处是入口清晰，坏处是很多人会把产品内工具误认为本机权限，所以记录里必须把本地路径和上传副本分开。
Codex 本地路线的记录重点是“工作区和审批”。要写明当前目录、是否允许写入、是否联网、哪些命令已经运行、哪些命令需要人工确认，以及是否触碰了上级目录。对于代码任务，这种记录比泛泛说“让 Codex 看一下项目”更有价值，因为后续审查可以顺着 diff、测试输出和命令历史确认 agent 没越界。
Claude Code 路线的记录重点是“规则和模式”。如果启用了 auto、dontAsk 或 bypassPermissions，记录里必须同时写出隔离条件：是不是一次性 checkout，是否删除了真实 .env，是否有 deny patterns，是否只允许测试账号。没有这些条件，跳过确认并不是效率优化，而是把可见性问题变成不可审计的执行问题。
还要把“谁负责最后一步”写清楚。ChatGPT 适合给出解释、整理表格或生成可下载文件，但把结果落回真实仓库、真实后台或真实客户数据时，通常需要人工或本地 agent 执行并复核。Codex 或 Claude Code 可以直接改文件，但也要把 review owner、测试命令和回滚方式留在记录里。这样权限不是一句信任声明，而是一套能交付、能审查、能撤回的操作链。
多人协作时，这个记录还能避免重复授权。下一个人不需要重新问 ChatGPT 为什么看不到桌面文件，也不需要盲目把 Claude Code 提到 bypassPermissions；他可以先看文件状态、执行位置和停止条件，再决定是继续当前路线、推送分支、补上传材料，还是把敏感样本缩小。对团队来说，这比“哪个 agent 最强”的讨论更接近真正的生产安全。
如果任务跨越两个界面，交接记录更重要。比如先让 ChatGPT 读上传的合同，再让 Codex 修改仓库里的解析器，最后让 Claude Code 跑本地回归测试，这三步看到的文件并不相同。记录要把每一步的输入、输出、下一步接管方式写清楚，避免后一个 agent 继承了前一个 agent 并没有拥有的上下文。
权限记录还应该包含失败后的处理方式：ChatGPT 看不到文件时，是补上传、改用 GitHub，还是切到本地 agent；Codex 本地缺依赖时，是安装依赖、改用容器，还是只做静态审阅；Claude Code 触发 deny 时，是缩小任务，还是由人手动处理敏感段。失败路径写清楚，团队才不会用更大的权限掩盖更小的路线错误。
另一个细节是输出回写。上传给 ChatGPT 的文件副本不会自动改回你的本地源文件；云端 agent 改的是远程 checkout；本地 agent 才能直接产生本地 diff。交接记录要说明结果是建议、补丁、生成文件，还是已经落盘的代码改动，否则后续执行者很容易把“已分析”误认为“已修改”。这也能防止重复执行和遗漏复核。
这份记录不需要很长，但应该足够让另一个人复现判断：这个任务为什么不用 ChatGPT upload，为什么必须留在本地，为什么可以或不可以联网，为什么某个目录被排除。能写出这段话，说明权限已经被拆成具体动作；写不出来，就先缩小样本或改用只读分析。
| 记录项 | 要写清什么 | 对应风险 | | 文件入口 | upload、Library、GitHub、workspace 或 GUI | 避免误以为 agent 自动看到本机 | | 执行位置 | ChatGPT 产品环境、本地 shell、cloud clone 或连接主机 | 避免把云端和本地状态混淆 | | 授权动作 | read、write、command、network、GUI | 避免把可见性当成全权执行 | | 停止条件 | .env、secrets、客户数据、未提交商业代码 | 避免为了省事扩大泄露面 |
常见问题
为什么 ChatGPT Agent 有终端却不能读我的本地文件夹？
因为那个终端属于 ChatGPT 产品环境，不是你当前项目里的本机 shell。它能处理上传、Library、连接器或授权仓库里的内容，但不会自动挂载你的桌面目录。
ChatGPT Agent 能处理整个 repo 吗？
可以，但要通过支持的路线交给它，比如 GitHub 授权或精简后的代码包。若任务依赖未提交改动、本地测试、依赖缓存或私有环境变量，Codex 本地或 Claude Code 本地通常更合适。
Codex 本地是不是天然更安全？
不天然。它更容易验证，因为工作区、命令和 diff 在本地可见；真正的安全来自 sandbox、profile、审批、writable root、网络策略和你是否隔离了敏感文件。
Codex 手机端会看到手机里的文件吗？
不要这样理解。手机端更像控制器，文件和凭据仍属于连接的主机或云端任务。手机本地文件也需要单独上传或交给合适入口。
Claude Code 的 bypassPermissions 是不是等于能看所有东西？
不是。它主要意味着跳过普通确认提示。是否能读到路径还受本地环境、规则和隔离范围影响；这种模式只应在你愿意信任的一次性环境里使用。
.env 文件应该怎么处理？
默认不要上传。用 deny 规则、脱敏 fixture、临时环境或本地命令验证行为。让 agent 看到变量是否存在可以，但不要打印真实密钥。
什么时候用 Computer Use？
当可见界面本身是证据时使用，例如设置页、浏览器流程、桌面 app 或 GUI bug。普通文件读取应优先用文件、仓库、日志或命令路线。