AI Code With · Codex 自动化、权限与浏览器工作流
Codex 真正进入自动化以后，问题会从“能不能运行”迅速变成“它到底能做什么、失败了谁能看懂、出了问题怎么停”。
很多自动化事故并不是 Codex 不会执行任务，而是边界没有写进流程：权限失败就直接开 full access；codex exec 跑通一次就塞进 CI；Playwright MCP 能打开浏览器以后，就让它登录后台、填写、提交、发布，一口气做完。
这三件事看起来分别属于权限、命令行和浏览器，其实是一条完整链：Permission Profile 决定 Codex 能碰哪里；codex exec 决定任务怎样非交互执行并留下证据；Playwright MCP 把自动化从本地工作区扩展到真实网页、Cookie 和账号操作。
自动化不是把人拿掉，而是把原本靠人盯着的边界，写进权限、输入输出、确认点和回滚流程。
1. 自动化上线前，先回答 5 个问题
| 问题 | 为什么重要 | 典型控制方式 |
| 能读什么 | 读取也可能暴露敏感信息 | read-only、workspace roots、浏览器域名范围 |
| 能写什么 | 改文件、填表、发布内容风险不同 | workspace 权限、分阶段操作、人工确认 |
| 能联网到哪里 | 外部内容可能带 prompt injection，Secret 可能外泄 | 域名白名单、最小网络权限 |
| Key 给谁 | 整个 Job 都能读 Secret 会扩大暴露面 | 只在需要步骤注入 |
| 失败怎么停 | 自动重试可能覆盖现场或重复高风险动作 | 退出状态、JSONL、日志、回滚点 |
2. 权限不够时，先看它想访问哪里，不要先开最高权限
Codex 提示权限不足时，最高权限确实可能最快让任务继续，但也是最容易留下长期风险的办法。
当前 Permission Profiles 仍处于 Beta。原稿按当前官方文档整理了三个常用内置 Profile：
| Profile | 适合任务 | 建议 |
| :read-only | 阅读、解释、审查，不需要写文件 | 默认从这里开始 |
| :workspace | 修改当前 workspace roots 内文件 | 大多数编码任务 |
| :danger-full-access | 明确需要广泛本地访问 | 只在确有必要且风险已确认时使用 |
如果只是解释报错，read-only 已经够；如果只是改当前项目，用 workspace；只有明确需要访问工作区外文件或系统级资源时，才考虑更高权限。
Permission Profiles 与旧 sandbox 配置不要叠在一起
当前权限体系与旧 sandbox_mode / sandbox_workspace_write 是不同逻辑。迁移时不要在活跃配置里同时保留两套相互覆盖的安全模型。
当权限行为与预期不一致时，首先确认到底是哪套规则在生效，而不是继续增加更多配置。
做一个最小权限实验，比看十张表更有用
• :read-only：读取文件成功，写入应被阻止。
• :workspace：在项目内创建一个无害测试文件。
• 尝试项目外的无害写操作，确认被拒绝或需要额外权限。
• 删除测试文件，恢复原配置。
以后权限失败时，先看被拦的是哪个路径、域名或命令，再问这个动作是否真的是当前任务必须的。
3. AI Code With 在自动化里最适合出现在哪一层？
如果你的自动化本来就通过 AI Code With 调用不同模型，它更适合承担“模型 API、Key 管理和调用归因”这一层，而不是承担 Codex 权限或浏览器安全。
例如长期 CI 可以单独创建一个用途明确的 Key；如果任务只需要访问 AI Code With 的 Codex API，就围绕当前文档核实的 API 域名做最小网络授权，再通过 Usage Records 核对调用是否来自预期 Key 和模型。
这里的边界很重要：AI Code With 能告诉你某次模型调用是否经过它、用了哪个 Key、产生了什么用量；但它不会替 Codex 决定哪个本地目录可写，也不会替 Playwright 判断“发布”按钮是否应该自动点击。
4. codex exec：适合脚本和 CI，但不要把它当成普通 shell
codex exec 是 Codex 的非交互入口，适合脚本、定时任务和 CI。最简单的调用很直接：
codex exec "summarize the repository structure and list the top 5 risky areas"
真正重要的是输入输出契约。Agent 在过程中可能调用工具、执行命令、遇到权限拒绝或中途失败。只看最后一句自然语言文本，自动化很容易变成黑盒。
stdout、stderr 和结构化输出要分开
当前 non-interactive 模式会把过程信息和最终结果分开：你可以把最终输出交给下游，同时保留过程日志。
codex exec "generate release notes for the last 10 commits" > release-notes.md
如果下游还需要判断任务过程中发生了什么，就应该看结构化事件，而不是解析大段自然语言日志。
--json：给自动化黑盒开一扇窗
codex exec --json "summarize the repo structure" | jq
JSONL 事件流让程序可以按事件类型处理 thread、turn、item 和 error，而不是假设“某一行永远是结果”。
解析时应按 type 分支、允许未知事件通过，并显式处理完成与失败状态。下游需要固定字段时，再用输出 Schema 约束最终结果。
一条能审查的 exec 流水线，至少要留下这些证据
• 任务 Prompt 与允许范围。
• stderr 过程日志。
• JSONL 事件或至少失败事件。
• 退出状态。
• 项目原有 test / lint / build 结果。
• 发生文件修改时的 Git diff。
• 最终产物和验收字段。
这样失败时才能分清：认证、权限、工具命令、测试，还是模型输出结构出了问题。
5. 自动化里的 Key 不应该属于整个 Job
如果把模型 Key 设置成整个 CI Job 都能读取的环境变量，那么 checkout 后的依赖安装、测试、构建钩子和其他步骤都可能共享同一 Secret 暴露面。
更稳的原则是：Key 来自 Secret 管理系统，只交给真正调用 Codex 的那一个步骤或进程，不进入 YAML、仓库、Prompt 和日志。
CODEX_API_KEY=<from-secret> codex exec --json "triage open bug reports"
如果团队使用 AI Code With，可以给 CI 单独创建一个低暴露面的 Key，并用后台调用记录做归因；但 CI 平台的 Secret 注入、PR 事件信任和仓库权限仍由 CI 自己负责。
6. Playwright MCP：能打开浏览器，只证明连接成功
Playwright MCP 很容易让人产生错觉：浏览器能打开，就代表后台发布、表单提交甚至支付流程都能放心自动化。
现实里浏览器不只有公开网页，还有登录状态、Cookie、订单、后台按钮、发送消息、删除和权限变更。能导航到页面，只证明 Server、浏览器和 Codex 的调用链通了。
Microsoft 当前官方 README 给出的 Codex 添加方式是：
codex mcp add playwright npx "@playwright/mcp@latest"
也可以配置到 ~/.codex/config.toml：
[mcp_servers.playwright]
command = "npx"
args = ["@playwright/mcp@latest"]
第一次不要拿登录后台开局。选一个公开页面，只让 Codex 读取页面标题和当前 URL，先把 Server 启动、浏览器导航和结果回传三件事分别验证。
Playwright MCP 官方明确说明：它不是安全边界
当前 Playwright MCP README 明确指出，allowed-origins / blocked-origins 等参数只是限制和护栏，不能替代真正安全隔离，也不能完全处理重定向风险。
默认文件访问会限制在 workspace roots 或当前目录；放开 unrestricted file access 会扩大文件范围。官方对 Secrets 替换同样强调，它是便利机制，不是安全边界。
浏览器自动化最终仍要依赖客户端权限、最小范围、隔离和明确确认点。
7. 把浏览器任务拆成：读取 → 准备 → 提交
| 阶段 | 典型动作 | 推荐策略 |
| 读取 | 打开页面、读取标题、抓取公开信息 | 优先只读，可作为首次验证 |
| 准备 | 填写表单、上传待确认文件、生成草稿 | 允许编辑，但不触发最终动作 |
| 提交 | 发布、支付、发送消息、删除、改权限 | 单独确认，必要时人工执行 |
“帮我把流程跑完”听起来很省事，实际上把所有风险都藏进“跑完”两个字。更好的 Prompt 要写清允许域名、页面范围、是否能输入数据、哪些按钮不能点，以及最后必须返回什么证据。
登录状态不是免费上下文
如果 Playwright MCP 使用已有登录状态，Agent 可能看到账号名、内部页面、订单、Cookie 或其他敏感数据。日志和截图要脱敏，浏览器配置目录与 Token 不能进入仓库。
页面文字、issue、评论、第三方链接都应该当成不可信输入，不能让网页本身决定接下来允许哪些自动化动作。
8. 一个现实案例：让 Codex 自动填 CMS，但停在“保存草稿”
假设你每天要把已经审核通过的 Markdown 文章填进 CMS。低质量自动化通常会直接写一句：
“打开后台，把今天的文章发出去。”
这句话的问题不是不够详细，而是没有任何安全边界。更可控的流程可以是：
1. codex exec 读取“已通过审核”的文章文件
2. 输出结构化 JSON：标题、摘要、正文路径、分类
3. Playwright MCP 打开指定 CMS 域名
4. 填入标题、正文、分类
5. 保存为草稿
6. 返回草稿 URL + 关键页面证据
7. 停止
8. 人工确认后再发布
如果第 1 步失败，是文件 / exec / 权限问题；第 3 步失败，是 MCP / 浏览器链路问题；模型请求 401 是 Provider / Key 问题；真正的“发布”动作则被单独留在人类确认点。
这就是高质量自动化的价值：不仅能跑，也知道每个阶段是谁负责、失败证据在哪里、怎么回滚。
9. 自动化中断在未知状态时，先停，不要继续点
浏览器任务最危险的一种状态是：你不知道上一步到底成功没有。比如提交按钮点过了，但页面没跳转；网络超时，后端可能已经接收请求；删除操作没有返回确认。
这时候正确策略不是让 Agent“再试一次”。先保存当前页面、最后一个工具调用、Server 日志和可见状态，再决定是否继续。重复点击可能把一个可恢复问题变成重复提交、重复支付或多次删除。
10. 自动化上线前的 12 项检查
□ 任务默认从 :read-only 或最小权限开始。
□ 需要写文件时只开放当前 workspace。
□ 没有同时混用新的 Permission Profiles 和旧 sandbox 配置。
□ 网络只允许任务实际需要的域名。
□ API Key 只进入真正需要调用模型的步骤。
□ codex exec 保存 stderr、退出状态和必要的 JSONL 事件。
□ 修改代码后会跑项目原有 test / lint / build。
□ 发生文件修改会保留 Git diff。
□ Playwright MCP 首次验证只使用公开页面和只读动作。
□ 浏览器登录状态、Cookie 和截图不会进入仓库。
□ 发布、支付、删除、权限变更等高风险动作有独立确认点。
□ 未知状态中断时先保存证据，不自动重复执行。
11. 最后：真正成熟的自动化，不是“一键到底”
Permission Profile 决定 Codex 能碰哪里；codex exec 决定非交互任务能不能被审计；Playwright MCP 决定浏览器里能操作到什么程度。
把这三层接起来以后，最重要的不是让所有步骤都无人值守，而是让低风险动作尽量自动，高风险动作有明确确认点，每一次失败都有日志、状态和回滚。
自动化不是把人拿掉，而是把该由人做判断的地方留下来。
AI Code With 如果进入这条链，最适合负责模型 API、Key 和调用记录，让模型调用本身可管理、可归因；Codex 的本地权限、CI 安全和浏览器动作边界仍然由对应执行层负责。这样产品承接自然，也不会把能力边界写混。
资料来源与核对说明
本文由 Codex 权限、codex exec、Playwright MCP 三篇原稿合并重写，并按当前公开文档核对关键命令和安全边界。Permission Profiles 仍可能变化，Playwright MCP 的配置参数与浏览器能力也可能随版本更新，正式落地应以当天官方文档和当前 CLI help 为准。
OpenAI Codex Permissions：https://developers.openai.com/codex/permissions
OpenAI Codex Non-interactive mode：https://developers.openai.com/codex/noninteractive
Microsoft Playwright MCP：https://github.com/microsoft/playwright-mcp
AI Code With Codex 文档：https://docs.aicodewith.ai/zh/docs/codex-cli
