# ChatGPT Agent 本地文件解决办法：Claude Code 和 Codex 权限区别 > ChatGPT Agent 本地文件解决办法不能一概而论：先用上传或 Library，GitHub 适合只读查询，代码修改交给 Codex 本地，MCP 桥接要当高风险方案。 - URL: https://blog.laozhang.ai/zh/posts/chatgpt-agent-local-files-claude-code-codex-permissions - Published: 2026-05-23 - Updated: 2026-06-01 - Author: AI Free API Team (https://blog.laozhang.ai/zh/about) - Topic: 开发工具与智能体 - Tags: ChatGPT Agent, OpenAI Codex, Claude Code, AI 编程工具, 本地文件 --- ChatGPT Agent 看不到本地文件，不是因为它“能力不够”，而是因为它默认并不运行在你的当前电脑文件夹里。它能处理你上传、放入 Library、通过连接器授权或通过 GitHub 路线交给它的内容，但这和把整个桌面目录挂载给 agent 是两回事。 Codex 本地和 Claude Code 本地的出发点不同。它们通常从你选中的项目、仓库或终端会话开始，所以会显得更像“能看到本地文件”。但这也不是无限权限：Codex 还有 read-only、workspace-write、danger-full-access、网络和审批策略；Claude Code 也有读取、编辑、Bash、allow/ask/deny、模式和敏感文件规则。 截至 2026 年 6 月 1 日，最稳的判断不是问“哪个 agent 更强”，而是先问三个问题：文件现在在哪个界面里，agent 通过什么路线拿到它，接下来要允许读取、写入、执行命令、联网还是操作图形界面。只要这三个问题没回答清楚，就不要为了省事直接开全权限。 ![ChatGPT Agent、Codex 与 Claude Code 本地文件权限路线图](https://blog.laozhang.ai/posts/zh/chatgpt-agent-local-files-claude-code-codex-permissions/img/cover.webp) | 场景 | 正确入口 | 先做什么 | 不要做什么 | | 一份文档、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 Agent 的文件入口路径](https://blog.laozhang.ai/posts/zh/chatgpt-agent-local-files-claude-code-codex-permissions/img/chatgpt-file-entry-paths.webp) | ChatGPT 路线 | 适合什么 | 边界 | | 上传文件 | PDF、表格、图片、日志包 | 看到的是上传副本 | | Library | 复用此前上传或生成的文件 | 不是本地磁盘镜像 | | 连接器 | 云端 app 或数据源 | 受账号、区域、工作区和授权限制 | | GitHub app | 被选择的仓库 | 可读、搜索、引用，不负责编辑或推送代码 | | Agent 浏览器/工具 | 网页任务和产品内操作 | 不是任意主机文件系统权限 | ## 按风险半径排序的安全解决办法 很多“让 ChatGPT 读取本地文件”的教程会直接跳到自建 MCP、tunnel、共享文件夹、远程桌面或脚本桥接。这些方案不一定错，但它们不该是默认第一步。更稳的排序是：先给最小副本，再给受控云端入口，最后才考虑 live bridge。 | 解决办法 | 适合场景 | 风险半径 | 停止规则 | | 上传或 Library | 读一份文档、表格、日志、图片或报告 | 如果文件已脱敏且范围小，风险最低 | 文件里有 secrets、客户导出或整包目录时停止 | | 连接器或 GitHub | 数据本来就在云端 app 或已选仓库 | 中等，取决于账号、组织和授权边界 | 需要未提交改动、本地测试或代码修改时停止 | | Codex 本地 / Claude Code 本地 | 需要改 repo、跑测试、看生成物、读本地日志 | 中到高，取决于 sandbox、写入范围、命令和网络 | 扩大到 workspace 外或打印 secrets 前停止 | | 沙箱或 manifest 交接 | 可以把任务做成只含必要文件的工作区 | 受控，前提是 mount、文件和运行配置都很窄 | manifest 拉进 home 目录或把 secret 写进 prompt 时停止 | | 自建 MCP、tunnel 或 live file bridge | 你能审计桥接层，且确实需要重复访问窄目录 | 高，因为远程对话面变成了活的本地数据入口 | 除非只暴露窄目录、尽量只读、可丢弃、可审计且无 secrets，否则停止 | | 手工脱敏 fixture | 真实环境敏感，问题可用小样本复现 | 隐私风险最低，但准备更慢 | fixture 已经不能复现实际问题时停止 | OpenAI 的 sandbox manifest 思路也指向同一个原则：工作区要明确，路径应相对工作区，mount 要窄，secrets 不应写进 prompt 或生成物。放到 ChatGPT Agent 场景里，就是先准备一个可解释的输入包：一个文件、一个脱敏日志包、一个连接器、一条仓库路线，或者一个隔离工作区。 中文读者最容易卡在“GitHub 已授权”和“能改代码”之间。ChatGPT 的 GitHub 路线可以帮你读仓库、搜索文件、引用代码位置，但它不是把 agent 放进你的本地 checkout，也不是自动创建 PR 的执行通道。真正要改代码、跑测试、看未提交 diff、读生成文件或接本地服务时，应该把任务切回 Codex 本地或 Claude Code 本地，并在工作区、命令、网络和停止规则上写清边界，保留交接记录。这样既不浪费 ChatGPT 的读取能力，也不会把只读连接器误用成代码执行权限。 真正高风险的是为了方便暴露整台机器。如果你确实要走 MCP 或 tunnel，至少要使用一次性 profile、窄目录、尽量只读、无 `.env`、无 SSH key、无浏览器 cookie store、保留日志，并准备一键关闭。只要这些控制比任务本身还重，就说明 upload、Library、GitHub 只读查询或本地 coding 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` 要停止。只要你说不出这句话，就说明任务还没有拆到可授权的程度。 ![Codex 与 Claude Code 本地权限层对比](https://blog.laozhang.ai/posts/zh/chatgpt-agent-local-files-claude-code-codex-permissions/img/local-agent-permission-layers.webp) | 层级 | 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。 ![五类文件状态和安全第一步](https://blog.laozhang.ai/posts/zh/chatgpt-agent-local-files-claude-code-codex-permissions/img/five-file-state-checklist.webp) - 文档类：上传必要文件，不上传整个目录。 - 仓库类：用本地工作区，保留 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 授权或精简后的代码包。ChatGPT 的 GitHub 路线更适合读取、搜索和引用仓库内容，不是编辑、删除、创建、push 或开 PR 的代码执行路线。若任务依赖未提交改动、本地测试、依赖缓存、私有环境变量或代码修改，Codex 本地或 Claude Code 本地通常更合适。 ### 自建 MCP server 是安全的解决办法吗？ 可以成为方案，但只应作为窄范围桥接。把 MCP、tunnel、watched folder 当成比上传、Library、GitHub 只读查询和本地 coding agent 更高风险的路线：目录要窄，尽量只读，不放 secrets，能审计，能随时关闭。不要因为 ChatGPT Agent 看不到一个文件，就暴露 home 目录或生产 checkout。 ### Codex 本地是不是天然更安全？ 不天然。它更容易验证，因为工作区、命令和 diff 在本地可见；真正的安全来自 sandbox、profile、审批、writable root、网络策略和你是否隔离了敏感文件。 ### Codex 手机端会看到手机里的文件吗？ 不要这样理解。手机端更像控制器，文件和凭据仍属于连接的主机或云端任务。手机本地文件也需要单独上传或交给合适入口。 ### Claude Code 的 bypassPermissions 是不是等于能看所有东西？ 不是。它主要意味着跳过普通确认提示。是否能读到路径还受本地环境、规则和隔离范围影响；这种模式只应在你愿意信任的一次性环境里使用。 ### .env 文件应该怎么处理？ 默认不要上传。用 deny 规则、脱敏 fixture、临时环境或本地命令验证行为。让 agent 看到变量是否存在可以，但不要打印真实密钥。 ### 什么时候用 Computer Use？ 当可见界面本身是证据时使用，例如设置页、浏览器流程、桌面 app 或 GUI bug。普通文件读取应优先用文件、仓库、日志或命令路线。