fork 子代理在 claude -p、SDK 和 IDE 里也默认开启了
Claude Code 派子代理时，除了 Explore、general-purpose 这些类型，还有一种 fork 子代理（subagent_type: "fork"）。顾名思义，它是从当前对话分叉出去的一路，适合「带着已有背景，去另一条线上把一件事做完」。
在终端里它早就默认可用。CLI 2.1.302 把这个默认值推到了其他入口。
哪些入口变了
| 入口 | 2.1.302 起 |
|---|---|
| 终端交互模式 | 默认开启（和以前一样） |
claude -p | 默认开启 |
| Agent SDK | 默认开启 |
| 桌面版 | 默认开启 |
| VS Code | 默认开启 |
claude mcp serve | 始终不提供 |
也就是说，同一套提示词和工作流，在终端、脚本、SDK 应用和 IDE 里看到的子代理类型现在是一致的。以前常见的情况是：终端里 Claude 会主动 fork 一路去试方案，换到 claude -p 跑同样的任务却从不这么做，行为对不上。
claude mcp serve 把 Claude Code 作为 MCP 服务器暴露给别的客户端，这条路依旧不会提供 fork 子代理。
不想要怎么关
如果你的自动化流程对子代理类型很敏感，或者想先观察一阵再放开，用环境变量关掉：
bash
export CLAUDE_CODE_FORK_SUBAGENT=0
claude -p "梳理这个模块的依赖关系"在 SDK 应用里，把同一个变量传进 Claude Code 进程的环境即可。
顺带统一的：前台还是后台
同一版本还调整了子代理的运行方式，和上面的改动一起看更清楚：
- 桌面版和 VS Code：主对话派出的子代理一律在后台运行，和终端版一样，不再由 Claude 自己决定前台还是后台；
claude -p、Agent SDK、桌面版和 VS Code：子代理自己再派出的 Agent 调用，默认在前台运行。
简单理解：第一层子代理在后台并行，主对话不被卡住；子代理内部再分出去的活，默认顺序跑完再回来，避免层层后台、结果难以追踪。
对现有工作流的影响
- 用
claude -p做 CI 或批处理的，日志里可能开始出现 fork 子代理的调用，这是预期行为； - 子代理并发多了以后，记得关注用量，必要时给子代理指定更轻的模型；
- 同版本还把 prompt 和 agent 类型的钩子限制为同一事件最多同时跑 12 个，其余排队，子代理多的会话里钩子不会再一下子全挤上来。
小结
- 2.1.302 起 fork 子代理在
claude -p、Agent SDK、桌面版、VS Code 默认开启，与终端一致； - 关闭用
CLAUDE_CODE_FORK_SUBAGENT=0，claude mcp serve永远不提供； - 桌面版和 VS Code 的主对话子代理统一在后台跑，子代理再派的 Agent 默认在前台跑。
各个入口的行为对齐之后，在终端里调好的提示词，搬到脚本和 IDE 里更容易得到一样的结果。