一、拦截规则核心约束
凭据不得通过以下三种通道传递：
检测器基于传递方式做启发式匹配，不解析内容本身。即使参数里没有真实凭据，只要命中"可疑通道"模式，一律拦截。
二、触发场景
| git commit -m "短消息" | ✅ 放行 | 直接字面量参数 |
| git commit -m "$(cat <<'EOF'…)" | ❌ 拦截 | 子 shell 展开 + heredoc → 触发"临时文件"检测 |
| git commit -F /tmp/msg.txt | ❌ 拦截 | 从临时文件读取内容 |
| CUSTOM_AUTH=xxx git push | ❌ 拦截 | 环境变量传凭据 |
| curl -H "Authorization: Bearer xxx" url | ❌ 拦截 | header 参数含认证信息 |
最常见的误报：git commit 用 heredoc 写多行 message。这是开发者习惯写法，但 heredoc 在 shell 内部的展开机制被检测器归类为临时文件通道。
三、拦截后的行为
命令不会执行，AtomCode 返回错误：
[Error: Tool call blocked by security policy: credentials cannot be passed
through generic shell arguments, temporary files, or environment variables]
同时：
- 不回显被拦命令的完整内容（防止凭据二次泄露）
- 弹出 Policy Intervention 恢复菜单：
Security decision required
1. I completed it externally ← 在外部终端手动执行后确认
2. Skip this step ← 跳过，不执行
3. View safe instructions ← 查看安全操作指引
4. End task ← 结束当前任务
这是 fix(security): offer safe recovery after credential blocks（2026-08-11）引入的恢复合约，在 v5.0.6 合并窗口定型。
四、绕过方案
方案 A：改写命令形式（推荐）
把 heredoc 改成直接多行字符串：
# ❌ 被拦
git commit -m "$(cat <<'EOF'
add vps module
Co-Authored-By: …
EOF
)"
✅ 放行
git commit -m "add vps module
Co-Authored-By: …"
方案 B：本机终端执行
AtomCode 官方推荐路径。在独立终端里操作，完全不受此策略约束。
方案 C：拆分操作
先写文件，再用 git commit -F（本机终端可行；AtomCode 内仍可能被拦）。
五、版本演进时间线
| v5.0 | 2026-07-17 | 审批增强地基，安全模型主干定型 |
| v5.0.4 | 2026-08-04 | 无人值守会话默认拒绝高风险 bash |
| v5.0.5 | 2026-08-07 | 含 safety-stop / ledger history（文档锚点证实） |
| v5.0.6 | 2026-08-11~12 | credential-block 恢复合约定型，完整拦截+恢复菜单上线 |
结论：凭据通道拦截的启发式检测大概率在 v5.0.5 引入，而你现在看到的完整"拦截→恢复菜单→不回显"体验，是在 v5.0.6（2026-08-11）的 fix(security) 系列 commit 中定型的。
六、设计意图
这是一条纵深防御策略：
一句话总结：AtomCode 用启发式规则封死了 AI 通过间接通道泄露凭据的所有路径，代价是偶尔误拦正常的开发操作。
