把仓库交给 Codex 以前，先划出它需要看的范围。一次前端样式修改通常不需要生产数据库导出、客服聊天记录或云服务密钥。任务写得越具体，后面的授权越容易判断。
先做一次只读盘点
让 Codex 先运行 git status --short，再列出准备读取和修改的文件。检查项目里是否有 .env、私钥、证书、数据库备份、用户上传文件和包含真实账号的日志。只报告路径与类型，不输出文件内容。发现不相关的敏感目录，就把它排除在任务之外。
Codex 本地客户端默认关闭命令的网络访问，工作区写入也受沙箱限制。越过工作区或访问网络时，通常会进入批准流程。权限模式和组织策略可能调整这些边界，因此每次仍要看实际请求的命令、路径和目标站点。
密钥只从运行环境进入
真实密钥放在环境变量或团队认可的密钥服务中。仓库保留 .env.example 时，只写变量名和无效占位值。随后检查 .gitignore 是否覆盖本地环境文件，并用 git diff --cached 查看暂存内容。构建日志、测试快照和报错信息也要检查，因为密钥可能从命令输出进入日志。
用户数据用脱敏样本替代。保留字段形状、字符长度和边界情况即可，姓名、邮箱、电话、订单号与访问令牌应当改成不可回推的测试值。截图同样要遮住地址栏参数、账号头像、内部域名和通知内容。
提交前做两道检查
第一道检查是差异。逐文件查看新增行，确认没有环境文件、数据导出、临时截图和调试日志。第二道检查是仓库保护。GitHub 的推送保护能在识别到受支持的硬编码凭据时阻止推送，用户级推送保护会为公开仓库提供基础拦截，仓库与组织能力还会受到套餐和管理员设置影响。
推送保护不能代替人工检查，也不能保证识别所有自定义密钥。若凭据已经进入提交或日志，先在服务端撤销并轮换，再清理代码和历史记录。只删文件无法让已暴露的凭据恢复安全。
把检查写进任务单
可以要求 Codex 在改动前输出预计文件清单，在改动后运行 git diff --check、git status --short 和 git diff --cached。再用 git check-ignore -v .env 确认忽略规则确实命中目标文件。命令输出只保留状态和路径，任何疑似密钥都用固定占位符替换。
需要读取日志时，先复制最小片段到单独测试文件，删掉用户标识和请求头。任务结束后删除这份临时材料，并检查它没有进入暂存区。需要调用外部服务时，只允许目标域名和必要方法，先用测试账号验证。生产账号、管理员令牌和全量数据都不该成为排错的默认输入。
如果团队使用代码评审，再让审查者只看敏感文件边界、配置读取方式和新增日志。这个小范围复核常能发现功能测试看不到的暴露风险。
完成标准很朴素。代码能从环境读取配置，测试只用脱敏样本，暂存差异没有敏感文件，凭据扫描没有未处理告警。任何一项缺证据，就继续停在本地检查阶段。