1. 为什么我用了两个月 Codex 也没开 Full AccessCodex 是 OpenAI 推出的编码智能体能在本地读写文件、执行命令、跑测试、改配置。它最吸引人的地方是能动手而最让人犹豫的地方也是能动手。Full Access 是它权限模型里最放开的一档命令不再逐条审批沙箱限制也基本撤掉模型可以按自己的判断直接操作文件系统。听起来效率拉满但代价是——一旦路径理解错、命令拼错、清理逻辑写反作用对象就是你电脑里的真实文件而不是某个隔离副本。我这两个月用 Codex 做过文件整理、批量重命名、Markdown 转换、截图归档、表格清洗这些重复办公任务也让它改过几个小项目的构建脚本。Full Access 我短暂试过但日常一直保留审批和沙箱。原因很朴素没有一项任务逼我必须长期打开它。这篇就把我实际在用的settings.json权限骨架拆开讲配合逐项验证动作让你在本地复现权限边界自己判断什么时候该收紧、什么时候可以临时放开。适合谁看刚接触 Codex、不确定权限模式怎么选的人被要不要开 Full Access纠结过的人以及想给团队定一套默认安全配置的人。下面所有配置都可以直接复制改路径就能用。2. 先把 TaoToken 的接入准备好Codex 本身是客户端真正干活的是背后的模型服务。我这边统一走 TaoToken 做模型接入好处是 key 和额度集中管理切换模型不用改一堆环境变量。官网入口在 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 注册后在控制台生成 API Key。拿到 key 之后Codex 侧需要配置的是 base URL 和 key。base URL 用 https://taotoken.net/api 注意这个地址不带任何查询参数直接填就行。key 建议放环境变量不要硬编码进settings.json因为配置文件经常要分享或提交到仓库。# Linux / macOS export TAOTOKEN_API_KEYsk-你的key # Windows PowerShell $env:TAOTOKEN_API_KEYsk-你的key如果你用的是 Codex CLI 或带 Codex 能力的编辑器插件通常在设置里能找到 OpenAI Base URL 或 API Base 这类字段填https://taotoken.net/api模型名按你账号里可用的填。想先确认模型通不通可以直接在模型对话页发一条测试消息比在本地反复改配置快得多https://taotoken.net/models?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 。这一步做完你手里应该有三样东西可用的 API Key、base URL、一个能跑起来的 Codex 客户端。接下来才是权限配置的正题。3. settings.json 权限骨架可复制配置Codex 的权限行为由几层叠加决定全局settings.json、项目级配置、以及启动时的命令行参数。我习惯把安全默认值写进全局配置项目里只做微调。下面是我在用的骨架字段名以你当前 Codex 版本为准思路是通用的。{ approval_policy: on-request, sandbox_mode: workspace-write, sandbox_workspace_write: { writable_roots: [ /home/me/codex-workspace ], network_access: false }, full_auto_error_mode: block, history: { persistence: none } }逐项解释一下这几行是整个权限边界的核心。approval_policy控制什么时候需要你点确认。on-request表示模型在它认为需要时发起审批请求而不是每条命令都问、也不是完全不问。对比never等于放开审批和untrusted几乎全问on-request是我日常最舒服的档位。sandbox_mode是沙箱开关。workspace-write允许在工作区内写文件工作区外只读或直接拒绝。另外两个常见值是read-only只能读和danger-full-access对应 Full Access基本不拦。我长期停在workspace-write。sandbox_workspace_write.writable_roots明确列出可写目录。只写你真正需要它动的那个文件夹不要图省事写$HOME或盘符根目录。我专门建了codex-workspace所有任务副本都放里面。network_access: false表示沙箱内默认断网。需要联网装依赖时我会临时在项目级配置里放开任务结束再关掉而不是全局常开。full_auto_error_mode: block是兜底自动模式下遇到错误就停下不要自作主张继续往下执行。这条能挡掉不少连环误操作。history.persistence: none是我个人偏好避免命令历史里留下敏感路径。你可以按需改成save。配置改完用一条命令确认它被正确加载codex config show输出里应该能看到approval_policy和sandbox_mode与你写的一致。如果没生效多半是项目级配置覆盖了全局或者客户端读的是另一个路径的配置文件用codex config path查实际加载位置。4. 逐项验证确认权限边界真的生效配置写完不代表生效必须实测。我一般做四组验证每组都对应一个明确的应该被拦或应该通过。第一组工作区内写文件。在codex-workspace里让它新建一个文件codex exec 在当前工作区创建 test-permission.txt内容写 hello预期结果直接成功不弹审批。因为工作区可写。第二组工作区外写文件。让它往工作区外写codex exec 在 /tmp/outside-test.txt 写入 hello预期结果被沙箱拦下或弹出审批请求。如果它一声不吭就写成功了说明writable_roots没生效回去检查路径是否写对、是否被项目配置覆盖。第三组删除操作。在工作区里放一个测试文件让它删codex exec 删除当前工作区里的 test-permission.txt预期结果on-request下通常会请求确认。这一步是重点——删除是最危险的动作我宁可多点一次确认。第四组网络访问。让它尝试联网codex exec 用 curl 访问 https://example.com 并输出状态码预期结果network_access: false时被拒绝。需要联网的任务再单独放开。四组都符合预期说明你的权限骨架是有效的。我实测下来这套配置下 Codex 完成日常办公任务完全够用唯一多出来的动作就是偶尔点一下审批。5. 本篇常见错排查配置不生效权限还是全开。最常见原因是项目目录下还有一份.codex/settings.json或类似文件它的优先级高于全局配置。用codex config path确认实际加载的是哪一份把冲突项删掉或对齐。writable_roots写了但工作区外仍可写。检查路径是不是软链接。沙箱判断的是真实路径如果你写的是链接路径实际指向可能在别处。用realpath展开后再填。审批一直不弹命令直接执行。说明approval_policy实际是never或者启动时用了--full-auto之类的参数覆盖了配置。命令行参数的优先级最高检查你的启动脚本。沙箱报错说无法创建临时文件。有些工具会在/tmp或系统临时目录写缓存而沙箱只允许工作区可写。解决办法是把该临时目录加进writable_roots或者设置工具自己的缓存目录指向工作区内。开了网络访问后忘了关。这是我自己踩过的坑为了装依赖临时放开网络任务结束忘了改回来。建议把关网络写进任务收尾清单或者干脆用项目级配置任务结束删掉项目配置即可。Full Access 下误删文件能恢复吗。大概率不能尤其是没进回收站的删除。所以我的原则是能在工作区副本上做的绝不在原文件上做。备份和权限限制才是真正的保险。6. 什么时候临时开 Full Access以及长期怎么协作我的判断标准就三条答不上来就不开这项任务为什么不能在工作区里完成Codex 会修改哪些真实文件操作出错后文件能不能恢复三条都有明确答案再考虑临时开启而且开之前先备份。长期协作我更推荐另一条路把安全默认值固化下来把重复任务交给 Coding Plan 这类长期额度方案让 Codex 在受限权限下稳定跑。配置骨架和验证方法你已经有了剩下的就是按自己的任务类型微调writable_roots和审批档位。需要长期跑编码或 Agent 任务的话可以从 https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 了解额度方案接入细节和字段说明在文档里https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content key 管理在控制台https://taotoken.net/console?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 。最后留一句我自己的经验Codex 的权限模型不是用来限制它能力的而是用来限制它犯错时的影响范围。模型会不会犯错不由你控制但错误作用在副本还是原文件上完全由你的settings.json决定。
用了两个月 Codex，我为什么从没开过 Full Access：一份 settings.json 权限骨架与验证记录
1. 为什么我用了两个月 Codex 也没开 Full AccessCodex 是 OpenAI 推出的编码智能体能在本地读写文件、执行命令、跑测试、改配置。它最吸引人的地方是能动手而最让人犹豫的地方也是能动手。Full Access 是它权限模型里最放开的一档命令不再逐条审批沙箱限制也基本撤掉模型可以按自己的判断直接操作文件系统。听起来效率拉满但代价是——一旦路径理解错、命令拼错、清理逻辑写反作用对象就是你电脑里的真实文件而不是某个隔离副本。我这两个月用 Codex 做过文件整理、批量重命名、Markdown 转换、截图归档、表格清洗这些重复办公任务也让它改过几个小项目的构建脚本。Full Access 我短暂试过但日常一直保留审批和沙箱。原因很朴素没有一项任务逼我必须长期打开它。这篇就把我实际在用的settings.json权限骨架拆开讲配合逐项验证动作让你在本地复现权限边界自己判断什么时候该收紧、什么时候可以临时放开。适合谁看刚接触 Codex、不确定权限模式怎么选的人被要不要开 Full Access纠结过的人以及想给团队定一套默认安全配置的人。下面所有配置都可以直接复制改路径就能用。2. 先把 TaoToken 的接入准备好Codex 本身是客户端真正干活的是背后的模型服务。我这边统一走 TaoToken 做模型接入好处是 key 和额度集中管理切换模型不用改一堆环境变量。官网入口在 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 注册后在控制台生成 API Key。拿到 key 之后Codex 侧需要配置的是 base URL 和 key。base URL 用 https://taotoken.net/api 注意这个地址不带任何查询参数直接填就行。key 建议放环境变量不要硬编码进settings.json因为配置文件经常要分享或提交到仓库。# Linux / macOS export TAOTOKEN_API_KEYsk-你的key # Windows PowerShell $env:TAOTOKEN_API_KEYsk-你的key如果你用的是 Codex CLI 或带 Codex 能力的编辑器插件通常在设置里能找到 OpenAI Base URL 或 API Base 这类字段填https://taotoken.net/api模型名按你账号里可用的填。想先确认模型通不通可以直接在模型对话页发一条测试消息比在本地反复改配置快得多https://taotoken.net/models?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 。这一步做完你手里应该有三样东西可用的 API Key、base URL、一个能跑起来的 Codex 客户端。接下来才是权限配置的正题。3. settings.json 权限骨架可复制配置Codex 的权限行为由几层叠加决定全局settings.json、项目级配置、以及启动时的命令行参数。我习惯把安全默认值写进全局配置项目里只做微调。下面是我在用的骨架字段名以你当前 Codex 版本为准思路是通用的。{ approval_policy: on-request, sandbox_mode: workspace-write, sandbox_workspace_write: { writable_roots: [ /home/me/codex-workspace ], network_access: false }, full_auto_error_mode: block, history: { persistence: none } }逐项解释一下这几行是整个权限边界的核心。approval_policy控制什么时候需要你点确认。on-request表示模型在它认为需要时发起审批请求而不是每条命令都问、也不是完全不问。对比never等于放开审批和untrusted几乎全问on-request是我日常最舒服的档位。sandbox_mode是沙箱开关。workspace-write允许在工作区内写文件工作区外只读或直接拒绝。另外两个常见值是read-only只能读和danger-full-access对应 Full Access基本不拦。我长期停在workspace-write。sandbox_workspace_write.writable_roots明确列出可写目录。只写你真正需要它动的那个文件夹不要图省事写$HOME或盘符根目录。我专门建了codex-workspace所有任务副本都放里面。network_access: false表示沙箱内默认断网。需要联网装依赖时我会临时在项目级配置里放开任务结束再关掉而不是全局常开。full_auto_error_mode: block是兜底自动模式下遇到错误就停下不要自作主张继续往下执行。这条能挡掉不少连环误操作。history.persistence: none是我个人偏好避免命令历史里留下敏感路径。你可以按需改成save。配置改完用一条命令确认它被正确加载codex config show输出里应该能看到approval_policy和sandbox_mode与你写的一致。如果没生效多半是项目级配置覆盖了全局或者客户端读的是另一个路径的配置文件用codex config path查实际加载位置。4. 逐项验证确认权限边界真的生效配置写完不代表生效必须实测。我一般做四组验证每组都对应一个明确的应该被拦或应该通过。第一组工作区内写文件。在codex-workspace里让它新建一个文件codex exec 在当前工作区创建 test-permission.txt内容写 hello预期结果直接成功不弹审批。因为工作区可写。第二组工作区外写文件。让它往工作区外写codex exec 在 /tmp/outside-test.txt 写入 hello预期结果被沙箱拦下或弹出审批请求。如果它一声不吭就写成功了说明writable_roots没生效回去检查路径是否写对、是否被项目配置覆盖。第三组删除操作。在工作区里放一个测试文件让它删codex exec 删除当前工作区里的 test-permission.txt预期结果on-request下通常会请求确认。这一步是重点——删除是最危险的动作我宁可多点一次确认。第四组网络访问。让它尝试联网codex exec 用 curl 访问 https://example.com 并输出状态码预期结果network_access: false时被拒绝。需要联网的任务再单独放开。四组都符合预期说明你的权限骨架是有效的。我实测下来这套配置下 Codex 完成日常办公任务完全够用唯一多出来的动作就是偶尔点一下审批。5. 本篇常见错排查配置不生效权限还是全开。最常见原因是项目目录下还有一份.codex/settings.json或类似文件它的优先级高于全局配置。用codex config path确认实际加载的是哪一份把冲突项删掉或对齐。writable_roots写了但工作区外仍可写。检查路径是不是软链接。沙箱判断的是真实路径如果你写的是链接路径实际指向可能在别处。用realpath展开后再填。审批一直不弹命令直接执行。说明approval_policy实际是never或者启动时用了--full-auto之类的参数覆盖了配置。命令行参数的优先级最高检查你的启动脚本。沙箱报错说无法创建临时文件。有些工具会在/tmp或系统临时目录写缓存而沙箱只允许工作区可写。解决办法是把该临时目录加进writable_roots或者设置工具自己的缓存目录指向工作区内。开了网络访问后忘了关。这是我自己踩过的坑为了装依赖临时放开网络任务结束忘了改回来。建议把关网络写进任务收尾清单或者干脆用项目级配置任务结束删掉项目配置即可。Full Access 下误删文件能恢复吗。大概率不能尤其是没进回收站的删除。所以我的原则是能在工作区副本上做的绝不在原文件上做。备份和权限限制才是真正的保险。6. 什么时候临时开 Full Access以及长期怎么协作我的判断标准就三条答不上来就不开这项任务为什么不能在工作区里完成Codex 会修改哪些真实文件操作出错后文件能不能恢复三条都有明确答案再考虑临时开启而且开之前先备份。长期协作我更推荐另一条路把安全默认值固化下来把重复任务交给 Coding Plan 这类长期额度方案让 Codex 在受限权限下稳定跑。配置骨架和验证方法你已经有了剩下的就是按自己的任务类型微调writable_roots和审批档位。需要长期跑编码或 Agent 任务的话可以从 https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 了解额度方案接入细节和字段说明在文档里https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content key 管理在控制台https://taotoken.net/console?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 。最后留一句我自己的经验Codex 的权限模型不是用来限制它能力的而是用来限制它犯错时的影响范围。模型会不会犯错不由你控制但错误作用在副本还是原文件上完全由你的settings.json决定。
