Codex 做项目时常见密钥泄露错误和修复顺序

密钥泄露通常不是因为新手“故意不小心”，而是因为流程里少了几个停顿点。客户催、报错复杂、Codex 改得很快，你一边复制材料一边验证，真实 token、数据库 URL 或日志片段就可能混进提示词、代码、截图、提交记录和交付文档。

这篇是草稿，只做风险复盘参考，不替代专业安全响应。遇到真实泄露时，优先通知客户、轮换密钥、记录范围，再决定后续清理方式。还没有形成流程的，可以先看 密钥安全检查清单。

适合谁

适合已经开始用 Codex 改客户项目、但担心自己把敏感配置带进提示词、代码或提交记录的新手。尤其适合在交付前做一次风险复盘：我给工具看了什么、我提交了什么、客户还需要确认什么。

也适合做匿名案例整理的人。你可以把这些错误改写成自己的检查项，放进项目 SOP，而不是等问题发生后才临时补救。

不适合谁

不适合正在处理真实泄露事故但没有权限联系客户或轮换密钥的人。真实泄露需要按项目流程处理，不能只靠文章里的建议自行决定。

也不适合想用 Codex 自动完成高权限安全响应的人。工具可以帮你整理记录和检查范围，但授权、轮换、通知和最终判断必须由有权限的人负责。

风险提醒

发现疑似密钥泄露时，优先级不是继续完成原任务，而是停止传播、保留事实、通知客户、轮换凭证和确认影响范围。不要为了“看起来已经修好”而隐瞒或跳过记录。

错误一：把 .env 整个复制给工具

很多新手觉得“Codex 不看完整配置就修不好”，于是把 .env 或部署平台环境变量截图直接贴进对话。问题是，工具通常只需要变量名、报错位置、调用方式和脱敏后的样例，不需要真实值。

修复方式：立刻停止继续传播这份内容，把真实值改成 <redacted>，重新整理最小上下文。如果真实值已经进入客户仓库、公开 issue、聊天记录或交付文档，要提醒客户轮换相关密钥，并记录它可能出现过的位置。

错误二：在示例代码里硬编码 token

为了让 demo 快点跑起来，有人会把 token 写进 config.ts、测试脚本或 README。短期看很方便，长期看是高风险。示例代码会被复制、提交、截图、发给客户，也可能被构建工具打包进产物。

修复方式：改用环境变量读取，把示例值写成占位符。文档里只说明变量名和配置位置，不写真实值。提交前搜索 key、secret、token、password、credential，确认没有硬编码凭证。

错误三：忽略日志和截图

日志里常常包含请求 header、用户邮箱、订单号、内部接口和 token 片段。截图也可能露出后台域名、项目 ID、账号头像、余额、插件密钥。新手只盯着代码，容易忘记这些“非代码材料”也会泄露。

修复方式：交给 Codex 前先裁剪和遮挡。保留错误码、堆栈、时间点、文件路径和脱敏字段，删除身份信息和真实凭证。交付时也不要把未经处理的截图放进案例库或文章素材。

错误四：删掉文件后以为问题结束

如果密钥已经进入 git 提交，单纯删除文件不代表历史里没有了。别人仍可能从旧提交、PR diff、CI 日志或缓存里看到内容。这里最重要的不是“把痕迹藏起来”，而是尽快降低密钥继续有效的风险。

修复顺序：先通知客户暂停相关凭证使用，再轮换密钥或撤销 token，然后检查它出现过的地方。是否需要重写历史、清理远端缓存、关闭旧部署，要根据项目流程和客户授权处理。新手不要在没有确认的情况下自行改远端历史。

错误五：用生产环境做验证

有些任务看似只是修一个小 bug，但验证时会触发真实邮件、真实扣费、真实订单、真实用户通知或后台权限变化。Codex 可以生成验证步骤，却不知道客户业务后果。生产环境验证前必须确认范围。

修复方式：优先要求测试账号、测试密钥、沙箱环境和可回滚步骤。如果客户无法提供测试环境，就把风险写进范围说明：哪些只能做静态检查，哪些需要客户自行验证，哪些必须由有权限的人执行。

具体步骤：发现疑似泄露后的处理顺序

1. 暂停继续提交、发布、截图和转发。
2. 保存事实记录：发现时间、文件、提交、对话、日志或截图位置。
3. 判断是否是真实有效密钥，是否属于客户或第三方服务。
4. 通知客户或项目负责人，不擅自隐瞒。
5. 由有权限的人轮换密钥、撤销 token 或调整权限。
6. 清理当前工作区中的敏感内容。
7. 根据客户要求处理历史记录、CI 日志、部署缓存和文档。
8. 写复盘：泄露入口、影响范围、已完成动作、待确认事项。

给客户的说明模板

我在检查过程中发现某处可能包含敏感配置，已暂停继续提交和传播。
目前已记录：
- 出现位置：
- 涉及类型：
- 是否已进入提交记录：
- 我已做的本地清理：

建议由你在对应平台轮换或撤销该凭证。
在你确认前，我不会继续执行涉及授权、生产环境或真实数据的操作。

让错误不再重复

最有效的办法不是记住所有密钥格式，而是让流程固定下来：材料先脱敏，工具上下文受限，修改后看 diff，提交前搜索敏感词，交付时列出未覆盖范围。可以把 检查清单 和 模板库 做成每个客户项目的开工记录。

CTA：下一步

如果你还在判断这种项目能不能接，继续看 涉及密钥和权限的任务能不能接。它会帮你把“技术上能不能做”和“项目上该不该做”分开。需要写给客户的风险说明时，可以先用 Proposal 生成器 起草，再人工删改敏感内容。

免责声明

本文只用于 AI 工具实践风险复盘和草稿复核，不构成法律意见、安全响应方案、合规建议或对具体事故的处理承诺。真实泄露应以客户授权、平台规则、项目流程和专业复核为准；需要注册、授权、轮换或高权限操作的事项，应先记录并由客户确认。