如何保护 .env、密钥和隐私信息

很多人第一次把 Codex 接进真实项目时，最容易忽略的不是写错代码，而是敏感信息边界。

因为一旦进入真实仓库，你面对的就不只是代码，还有：

• .env
• API Key
• Token
• Cookie
• 数据库连接
• 第三方平台账号
• 用户手机号、邮箱、订单信息

这些内容如果处理不当，后果往往比改错一个按钮严重得多。

前置教程：哪些操作可以批准，哪些要先停一下
如果你还没有建立权限判断习惯，先完成前置教程，再看本篇。

依据来源：OpenAI Codex 官方手册中关于 security、approvals、secrets、workspace boundaries 的说明。

本篇目标

学完后，你应该能做到：

1. 识别项目里最常见的敏感信息。
2. 知道哪些文件默认不该让 Codex 乱动。
3. 知道如何在任务里提前写明敏感边界。
4. 知道截图、粘贴报错、提交代码时要遮什么。
5. 知道发现泄露风险时该怎么停下来。

先记住一句最重要的话

能让 Codex 看到的内容，不应该默认等于“可以随便处理的内容”

真实项目里，很多文件虽然就在仓库里，但并不代表应该随便读、随便贴、随便改。

哪些内容最容易出问题

配置型敏感信息

例如：

• .env
• .env.local
• .env.production
• 各类密钥配置文件
• 数据库连接配置

身份型敏感信息

例如：

• API Key
• Access Token
• Refresh Token
• Cookie
• Session 信息
• 第三方平台账号

业务型敏感信息

例如：

• 用户手机号
• 身份证号
• 邮箱
• 收货地址
• 合同内容
• 未公开业务数据

运维型敏感信息

例如：

• 服务器地址
• 内网域名
• SSH 配置
• 部署密钥
• CI/CD 密钥

使用 Codex 时，哪些文件默认要谨慎

你可以把下面这些当成“默认高敏感目录或文件”：

• .env
• .env.*
• secrets.*
• id_rsa
• known_hosts
• 云服务配置文件
• 各种账号配置目录

不是说永远不能碰，而是默认要先收紧边界。

在任务开头就把边界写出来

这一步很关键。

不要等 Codex 快要读到敏感文件了，你才临时补一句“别看这个”。

更好的做法是一开始就写：

本次任务的敏感信息边界如下：
1. 不要读取或输出 .env、.env.local、token、密钥、数据库连接信息。
2. 如果你判断任务必须依赖这些配置，请先停下来说明原因，不要直接读取。
3. 不要把任何账号、密钥、Cookie、手机号、邮箱原样写进回复。
4. 如果日志里出现敏感字段，请只保留必要的报错信息，并对敏感值做遮盖。

这一段非常值得长期复用。

什么时候不该把完整报错直接贴给 Codex

有些报错文本里会直接带出敏感信息，例如：

• 请求头里的 token
• 数据库连接串
• 完整文件路径
• 用户手机号和邮箱
• 第三方接口返回的账号信息

这时不要直接整段贴。

正确做法是先手动处理一遍，只保留真正和问题有关的部分。

例如：

原始报错里的 token、手机号、邮箱、完整域名我已经去掉。
下面是和问题相关的部分，请只根据这些信息分析：

然后再贴精简后的内容。

截图时最容易漏掉什么

很多人以为只要不截 .env 文件就安全了，其实远远不够。

截图里常见的泄露点还有：

• 编辑器右上角的账号头像
• 浏览器里的完整网址和参数
• Network 面板里的请求头
• 控制台里的 token
• 页面里的手机号、邮箱、订单号
• 提交记录里的仓库地址

所以你以后截教程图、问题图、交付图之前，至少过一遍这张清单：

1. 有无账号邮箱。
2. 有无手机号。
3. 有无 token 或密钥。
4. 有无内网地址。
5. 有无客户、用户、订单等业务隐私。

为什么“让 Codex 顺手帮我配置一下密钥”要谨慎

这类话听起来效率很高，但风险很大。

因为它往往意味着：

• 需要读取敏感配置
• 需要修改敏感配置
• 可能把真实密钥写进文件
• 可能把错误示例变成真实泄露

更稳的做法是把任务拆开：

1. 先让 Codex 告诉你应该改哪个配置位置。
2. 让它给出占位示例，不要写真实值。
3. 真实密钥由你自己手动填入。
4. 再让 Codex 只做“验证配置是否生效”的分析。

推荐你长期使用的安全任务模板

以后只要任务靠近配置、登录、模型接入、第三方接口，都可以在开头附上这段：

安全要求：
1. 不要读取或输出任何密钥、token、Cookie、.env 内容。
2. 如果任务需要配置敏感信息，请只告诉我应该改哪个位置，用占位符示例，不要写真实值。
3. 不要把敏感信息写入可提交文件。
4. 如果日志或报错中包含敏感字段，请只保留和问题有关的部分，并对敏感值做遮盖。
5. 如果你判断必须接触敏感信息才能继续，请先停下来说明原因。

这段足够通用，而且很适合中文用户长期复制。

如果 Codex 已经读到了不该读的内容怎么办

先不要慌，也不要继续推进任务。

你现在应该立刻做的是：

1. 停止当前任务继续扩大上下文。
2. 不要把这段敏感内容继续复制到别处。
3. 检查它有没有把敏感值写进文件、日志、总结或提交信息。
4. 如果已经写进文件，立刻让它移除，并重新检查 diff。
5. 如果是真实泄露级别的问题，及时更换密钥或令牌。

你可以直接这样说：

先停止当前任务。

请只做检查，不要继续修改：
1. 刚才的输出里是否包含 .env、token、密钥、Cookie 或其他敏感信息。
2. 这些内容是否被写入文件、日志、总结或提交信息。
3. 如果已经写入，请只移除这些敏感内容，不要扩大修改范围。
4. 最后告诉我还需要我手动处理哪些风险。

教程写作和对外展示时要特别注意

你这个站点后面会发布大量教程，这一点尤其重要。

因为“真实截图”“真实项目”“真实配置”很容易不小心把敏感内容带出来。

以后你在写教程时，建议长期坚持这几个规则：

1. 示例里的密钥全部用占位符。
2. 示例里的域名、用户名、邮箱、手机号全部脱敏。
3. 截图前先检查地址栏、终端、控制台和右上角账号信息。
4. 不把真实生产配置直接贴进教程正文。
5. 任何涉及登录态的图都先做遮盖。

什么时候可以让 Codex 处理配置文件

不是所有配置文件都不能碰。

可以处理的前提通常是：

1. 你已经明确知道要改哪里。
2. 文件里没有真实敏感值，或者你会自己手动填真实值。
3. Codex 只负责生成结构、占位符或解释配置意义。
4. 最终落地前你会自己再检查一遍。

也就是说，Codex 更适合帮你：

• 解释配置项
• 生成模板
• 检查格式
• 帮你验证配置有没有生效

而不是直接替你管理真实密钥。

完成标志

做到这里，如果你已经形成下面这些习惯，就说明本篇的目的达到了：

1. 知道 .env、token、Cookie、数据库连接都属于高敏感信息。
2. 知道任务一开始就要写清楚敏感边界。
3. 知道报错、日志、截图不能原样乱贴。
4. 知道真实密钥最好自己手动填，不让 Codex 直接代写。
5. 知道一旦发现泄露风险，要先停任务、查扩散范围、必要时更换密钥。

下一步建议

这组安全基础打完以后，下一波我建议继续补“团队边界”和“提交前安全检查”两篇。这样从个人使用到团队协作就能接上了。