Claude Code 新增 Shell 启动文件写入保护：acceptEdits 安全模型变更对无人值守部署的影响

如果你的团队在无人值守或 SDK 模式下以 acceptEdits 启用状态运行 Claude Code，6 月 2 日版本已经在不改变你配置的情况下改变了你的安全面。新的交互确认提示现在会拦截对 shell 启动文件和构建工具配置文件的写入——如果你的流水线假设这些写入是静默的，它将会卡住。

发生了什么

6 月 2 日的 Claude Code 版本（v2.1.157+）引入了两层安全干预措施，旨在防止 AI 生成的代码意外地为自身授予持久执行权限：

Shell 启动文件保护。 在写入 .zshenv、.zlogin、.bash_login 或 ~/.config/git/ 之前，Claude Code 现在会弹出明确的确认提示。这些文件在每次打开 shell 时都会执行——一次成功的写入可能安装一个持久钩子，在当前 Claude Code 会话范围之外以用户身份运行任意命令。该保护是无条件的：无论 acceptEdits 状态如何都会触发。

acceptEdits 构建工具配置文件保护。 启用了 acceptEdits 模式（Claude Code 无需逐编辑审批即可自动合并文件修改）的团队，现在对一类可授予代码执行权限的文件会看到额外的确认层。受保护的文件列表包括：

• .npmrc 和 .yarnrc*——可定义生命周期钩子和安装脚本
• bunfig.toml——同类文件，Bun 工具链
• .bazelrc——可指定自定义工具链可执行文件
• .pre-commit-config.yaml——在每次提交前执行钩子
• .devcontainer/——定义完整容器环境，包括启动脚本

这些不是无关紧要的配置文件。例如，一个恶意或意外制作的含有 scripts.preinstall 钩子的 .npmrc 将在该仓库中每次 npm install 时运行任意代码。新的保护措施阻止 acceptEdits 将这些文件视为普通源代码文件。

为什么 AI 工程团队应该关注

acceptEdits 模式在自主编程 agent 部署中十分常见。团队将 Claude Code 配置为后台 agent——通过 SDK 启动、由 CI 触发或通过 API gateway 路由——并依赖它在无需人工审批的情况下进行和合并更改。这是提升吞吐量的方式，也是被攻击的 prompt 或模型判断中的边界情况可能悄无声息地向开发者环境写入钩子的方式。

新的保护措施打破了 acceptEdits 是平铺覆盖的隐含假设。它现在对执行链中的任何文件类别都有划出例外。对于大多数只处理应用程序代码的团队而言，这是不可见的。但对于运行基础设施即代码 agent、脚手架生成器、devcontainer 更新器或 pre-commit 钩子管理器的团队，这是一个工作流变更。

同样值得注意的是被移除的 CLAUDE_CODE_OPUS_4_6_FAST_MODE_OVERRIDE 环境变量：任何设置了此覆盖以在 Opus 4.6 部署中强制快速模式的流水线，其效果都将悄然失效。该变量现在是一个空操作，但不会抛出错误——留下一个什么都不做的配置，可能误导未来的排查工作。

Router/Operator 视角

SDK 和 gateway 部署。 当你通过 Claude Code SDK（@anthropic-ai/claude-code）在 API gateway 或 TheRouter 后面部署 Claude Code 时，工具调用流仍然正常路由。变化的是当 Claude Code 子进程尝试写入构建工具配置文件时发生的事情：它不再静默地发出一个写入工具调用，而是会发出一个阻塞的提示，直到人工确认（或超时）。

如果你的基础设施以 --yes 或 CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC=1 包装 Claude Code 且没有人工在回路中，你需要验证你的部署现在是否会收到未处理的提示。该提示不会作为 API 错误暴露——它在 TTY 层面浮现。仅捕获 stdout/stderr 的无头运行器可能看不到它，程序将简单地挂起。

acceptEdits 范围审计。 现在正是审计你的 Claude Code agent 当前被允许写入哪些文件模式的好时机。模型默认不会将自己限制在应用程序代码中。如果你没有在 CLAUDE.md 或 settings.json 中配置显式的 ignore 模式或文件范围约束，你的 agent 可能已经在写入构建工具配置文件了。新的保护措施会拦截未来的此类操作，但不会对已经写入的内容进行追溯审计。

动态工作流关键词变更。 动态工作流的触发关键词从 workflow 更改为 ultracode。任何通过发送字面量 workflow 作为 prompt 前缀来触发动态工作流的 SDK 集成或 prompt 模板现在将悄然失败——请求将作为普通轮次处理，而不是动态工作流运行。如果你使用此功能，请检查你的 CLAUDE.md 文件和 SDK 包装 prompt。

需要关注的事项

• 验证你的无头流水线。 在暂存环境中运行一个会触发构建工具配置文件写入的测试轮次。确认你的运行器是否处理新的提示或挂起。
• 审计 acceptEdits 文件范围。 如果你的 agent 有合理理由更新 .npmrc 或 devcontainer 配置，请使用 settings.json 显式指定目录或文件模式。明确的范围比依赖模型的判断更安全。
• 移除 CLAUDE_CODE_OPUS_4_6_FAST_MODE_OVERRIDE。 如果任何流水线设置了此变量，请清除它——它是一个空操作，可能在未来的调试中造成误导。
• 如果你使用动态工作流，请将任何硬编码的 workflow 关键词触发器更新为 ultracode。

这里更广泛的模式是：Claude Code 的安全模型正在从"信任模型保持在范围内"向显式文件类治理成熟。将 Claude Code 视为黑盒并通过 API 层路由所有工具调用的运营商应该预期更多这样的文件写入边界，而不是更少，因为该模型正被部署在更高风险的环境中。