Claude Code 2.1.219：运维团队在部署前必须审查的三项治理变更

Claude Code 2.1.219 的 changelog 以大量 bug 修复为主，但其中三项变更会悄然改变运维部署的实际权限边界——不需要任何代码改动，新行为即会生效。

三项具体变更及对应配置项

sandbox.network.strictAllowlist — 新增，默认关闭。

2.1.219 之前，sandbox 遇到不在 allowlist 中的网络主机时会弹出权限对话框，用户可选择批准或拒绝。启用 strictAllowlist: true 后，拒绝将变为静默执行：任何不在 sandbox.network.allowedHosts 中的主机直接被阻断，不产生任何提示。

这对无人值守的运维部署意义重大。如果你在 CI 环境或 API gateway 后运行 Claude Code，旧行为会让未知主机的权限请求无限排队，没有人批准就意味着 agent 永远卡死。strictAllowlist 让你在配置中声明网络边界，操作系统层面执行，不存在回退到弹框的路径。

启用方式：

// .claude/settings.json 或 managed settings
{
  "sandbox": {
    "network": {
      "strictAllowlist": true,
      "allowedHosts": [
        "api.anthropic.com",
        "registry.npmjs.org",
        "github.com"
      ]
    }
  }
}

运维层面的影响：任何试图访问未声明端点的 agent——例如解析到未知云域名的 MCP server，或 model 自行决定拉取的包注册表——都将静默失败而非卡死。失败模式更清晰，但你也要承担随 agent 工具集演进而持续维护 allowlist 的成本。

嵌套 subagent 深度默认从 1 提升至 3，回滚需要显式配置。

2.1.219 之前，Claude Code 的 subagent 无法再生成自己的 subagent，深度上限为 1：主 agent 可以生成 worker，但 worker 只能在平坦的单层运行。从 2.1.219 起，默认上限是深度 3：主 agent 生成 subagent，subagent 再生成 subagent，再往下还可以再生成一层。

成本敞口是真实的。深度 1 时，一个 orchestrator prompt 生成 10 个 subagent 产生 11 次 Claude API 调用；深度 3 时，每个 subagent 理论上可再生成 10 个，每层再乘以 10——上限在 orchestrator 单轮结束前可达 1,111 次 API 调用。实际工作流不会打满上限，但错误配置的 agentic prompt 的"爆炸半径"在量级上扩大了一个数量级。

恢复旧的深度 1 行为：

# 在 shell 环境或 managed-settings env 中
export CLAUDE_CODE_MAX_SUBAGENT_SPAWN_DEPTH=1

或在 managed settings 中将其作为 env var 传入，settings 文件的 env 解析会在启动时生效。CLAUDE_CODE_MAX_SUBAGENT_SPAWN_DEPTH 是目前唯一的控制手段。

对通过 gateway 路由 Claude Code 的团队：每个生成的 subagent 会向上游 provider 发出独立的 API 调用。深度 3 嵌套意味着你可能在 token 计量中看到无法与顶层 orchestrator session 一一对应的突发流量。如果你使用 per-session 成本归因来做计费或分摊，这会打破"一次 CLI 调用 = 一个 session 的 API 流量"这个假设。

动态工作流规模默认从不限制改为"中等"（最多 15 个 agent）。

Claude Code 的 Dynamic Workflow 功能允许 model 编排可变数量的并行 agent 来完成任务。2.1.219 之前，规模指导是纯建议性的，默认不限制——model 可以按需启动任意数量的 agent。

2.1.219 将默认改为"中等"：目标少于 15 个并行 agent。这仍是建议性的（model 有充分理由时可以超出），但为 model 的规划提供了一个具体的锚点。

运维视角：如果你的 Dynamic Workflow 用于大规模代码分析或全仓库重构，且之前依赖不限制的 agent 数量，你现在有了一个可控的配置入口。

修改默认值：

// 任意 settings 文件（项目级、用户级、或组织 managed settings）
{
  "workflowSizeGuideline": "large"   // "small" | "medium" | "large" | "unrestricted"
}

或在交互式会话中通过 /config → "Dynamic workflow size" 修改。当前激活的规模指导现在也会显示在运行中工作流的状态栏，无需打开 settings 文件即可查看。

跨 provider 视角：这些设置在哪里配置、在哪里生效

三项设置均在 Claude Code 的 settings 层配置——项目级 .claude/settings.json、用户级或组织 managed settings——不在 Anthropic API 请求体中。这意味着：

• 通过 Bedrock、Vertex AI 或自定义 gateway 路由 Claude Code 的团队，行为与直接使用 Claude API 一致。sandbox 和 subagent 控制在客户端生效，请求到达路由层之前就已执行。
• gateway 层可观测性：你的路由代理能看到独立的 API 调用，但无法看到 Claude Code 客户端的深度或 network allowlist 状态。如需 subagent 深度的可见性，需在 SDK 层埋点，或读取 stream-json 输出中的 agent_turn 事件（2.1.219 新增的 --forward-subagent-text flag 可将深度 2+ 的 subagent 文本透传，以生成它的 tool_use id 为键）。
• Managed settings：通过 CLAUDE_CODE_SETTINGS_URL env var 下发 managed settings 的团队，三项设置均可集中控制，启动时生效，无需逐项目维护配置文件。

与其他 coding agent 的对比：Cursor Automations 和 Grok Build 的 agent spawn 治理在云端控制平面执行，运维人员可通过 dashboard 查看和限制 agent 数量。Claude Code 的治理在 CLI/SDK 边缘——灵活性更高，但需要主动部署 managed settings 才能在开发者工作站或 CI runner 机群中统一生效。

在 2.1.219 部署至生产前需要审查的清单

如果你在 CI 或无人值守模式运行 Claude Code：
启用 sandbox.network.strictAllowlist: true 并整理 allowlist。不启用时，未授权的网络调用在无人值守环境下只会永远排队等待批准。从现有日志中提取实际访问的主机，然后再开启。

如果你在大型代码库上运行 Dynamic Workflow：
确认你的工作流是否经常生成超过 15 个 agent。如果是，在部署 2.1.219 之前在 managed settings 中加入 "workflowSizeGuideline": "large" 或 "unrestricted"，或接受行为变更并在前几次运行中监控 token 消耗。

如果你做 per-session 成本归因：
深度 3 subagent 默认意味着顶层 session 归因不再能捕获一次 agentic 运行的全部成本。如需严格的 session 级成本边界，设置 CLAUDE_CODE_MAX_SUBAGENT_SPAWN_DEPTH=1；或更新归因逻辑，聚合单次 CLI 调用生成的整个 API 调用树。

额外一项：Opus 4.7 fast mode 现在会报错。
在 2.1.219 中，claude-opus-4-7 配合 speed: "fast" 会返回错误。与 Opus 4.6 不同，它不会静默回退到标准速度。如果你有任何 Claude Code 配置固定使用 Opus 4.7 并显式调用 fast mode，这些调用将失败。迁移到 Opus 5 或 Opus 4.8 以继续使用 fast mode。