claude agents transcript：外发与隐私

Claude Code 后台 Agent 的 transcript 外发行为并不直接等同于整个仓库被上传，但“任务在后台运行，所以数据不会出网”的推论同样不成立。热点材料将现象概括为“Claude Code 会定期把每个后台 Agent 的 transcript 发给其模型”。 现有材料尚不足以确认触发时机、transcript 的准确范围、接收模型，也不能推出“每次都发送完整 transcript”“统一发给父模型”或“后台与前台使用同一模型”。

排查 Claude Code 后台 Agent 的 transcript 外发行为时，先用 claude agents --cwd . 和 /list-agents 确认当前对象是顶层后台会话还是内部 subagent，再记录 Claude Code 版本、当前模型和实际请求发往的提供方。随后用带唯一标记的合成文件做一次最小测试，再决定是否需要脱敏、限权、更换模型路由或停止使用后台任务。

在验证结果出来以前，如果工作区里有真实密钥或客户数据，最稳妥的处理是不让后台 Agent 接触这些值，必要时先终止任务。现有资料没有证明 Claude Code 存在一个适用于所有版本、能够关闭 transcript 外发的通用开关，因此不能给出一个未经官方确认的“禁用命令”。

先分清 claude agents 和内部 subagent

claude agents 管理的是顶层后台会话。按相关工具链中的定义，这类会话各自对应独立的 Claude Code 进程，而不是某个前台命令内部派生出来的子任务。 内部 subagent 则属于单次 Agent 执行过程，由前台 Agent 创建、管理并接收返回结果。两者的进程边界、生命周期和消息路径不同，不能看到“background”就统一按同一种对象排查。

在支持相关功能的版本中，可以从两个入口观察后台对象：

claude agents --cwd .

进入 Claude Code 后还可以使用：

/list-agents

资料将 /list-agents、ListAgents 和 SendMessage 归为同一组跨会话协作功能，并称其适用于 Claude Code v2.1.224 或更高版本以及 macOS、Linux。这个版本条件需要按自己的目标版本重新确认，旧版上命令不存在并不奇怪。即使这些功能可用，SendMessage 也只是另一条跨会话消息路径：它增加了接收方可能看到的上下文，不能据此推断所有后台 transcript 都会沿着这条路径被汇总或转发。

排查时还要区分常被称为 transcript 的四层内容：完整消息历史、工具调用及工具输出、最终摘要，以及内部 subagent 返回给父 Agent 的结果。这四层不是同一个数据对象。尤其是“父 Agent 收到了一个摘要”，并不自动说明原始 transcript 已全部发送；反过来，“后台 Agent 自己调用了模型”，也不说明父 Agent 收到了它的全部历史。

上下文工程资料指出，模型执行任务时的上下文不只有用户当前输入，还可能包括系统提示词、Skills、CLAUDE.md、记忆以及工具结果。 可以把数据路径简化成：

任务与文件
  → 后台 Agent 进程
  → 组装系统提示词、Skills、CLAUDE.md、记忆和工具结果
  → 发往模型
  → 工具结果或会话记录进入后续上下文

因此，“进程独立”只说明执行状态相对独立，不构成数据不出网的保证。热点标题中的“its model”也不能自动改写成“前台使用的模型”或“父 Agent 使用的模型”；后台会话实际走哪个模型和提供方，需要从当前配置及请求日志确认。

上下文超限时，别把模型限制当成隐私开关

资料记录了 Claude Code 2026 年更新中的一种未知模型目录报错，原文如下：

"qwen3.7-flash-2026-07-15" isn't described by this version's model catalog; update Claude Code, or map it with behavesAs on a modelPicker row (or modelOverrides, if it is a provider id of a model this version knows). Until then auto-compact keeps this session within 200k tokens (the context window it assumes); if the model accepts more, append [1m] to the model name for 1M, or set CLAUDE_CODE_MAX_CONTEXT_TOKENS to its real window; CLAUDE_CODE_DISABLE_UNKNOWN_MODEL_WINDOW_ENFORCEMENT=1 restores the previous wait-for-the-API behavior.

这段报错针对的是资料所述版本无法识别该模型的情况。Claude Code 不知道模型真实上下文窗口时，先按 200k tokens 处理，并通过 auto-compact 把会话控制在这个假设范围内；它并不表示所有 Claude Code 模型都固定只有 200k 上下文。

处理这条报错时，可以更新 Claude Code，也可以按报错提示，通过模型选择器中的 behavesAs 映射模型；如果提供方 ID 是当前版本已知的模型，还可以使用 modelOverrides。由于现有资料没有给出完整配置结构，配置位置和字段格式应以报错所对应的版本为准。

如果模型提供方明确声明支持 1M 上下文，也可以在模型名称后追加 [1m]：

qwen3.7-flash-2026-07-15[1m]

也可以向 Claude Code 声明模型真实的上下文窗口。例如，下面的 1000000 仅适用于提供方明确给出这一数值的模型：

export MODEL_CONTEXT_WINDOW=1000000
export CLAUDE_CODE_MAX_CONTEXT_TOKENS="$MODEL_CONTEXT_WINDOW"

只有确实需要恢复旧有的“等待 API 返回”行为时，才考虑：

export CLAUDE_CODE_DISABLE_UNKNOWN_MODEL_WINDOW_ENFORCEMENT=1

这些设置处理的是上下文窗口识别和请求失败时机，不会阻止 transcript 进入模型请求，也不是隐私控制措施。[1m] 后缀和环境变量是否仍被目标版本支持，需要查对应版本的官方文档；资料只能证明它记录的那次报错及处理方式。 上下文膨胀和敏感数据外发需要分开处理：前者可以通过目录映射、上下文窗口配置或压缩处理，后者取决于 Agent 能读取什么以及请求最终发往哪里。

按数据级别决定少送、脱敏、改路由还是停用

“数据进入模型请求”“服务保留这份数据”“保留的数据用于训练”和“数据被对外公开”是四个不同问题。热点材料讨论的是后台 Agent 与模型之间的数据路径，现有资料不足以据此判断实际提供方会保留多久、是否用于训练或是否公开。排查时必须分别查看 Anthropic 以及实际模型提供方的数据政策；如果经过代理或兼容层路由，还要确认真正处理请求的是谁。

不同数据级别对应不同的控制方式：

对于公开代码，真正有效的控制点是缩小工作区和工具权限，而不是单纯相信 .gitignore。.gitignore 表达的是版本控制中的忽略规则，不是 Agent 的文件读取黑名单；只要工具进程有相应权限，仍可能通过其他命令读取文件。Skills、CLAUDE.md 和记忆文件同样需要检查，因为它们可能把与当前任务无关的背景持续带入上下文。

内部代码还要留意工具输出。Agent 读取过的源码、命令的标准输出和错误输出、环境变量以及日志，都可能作为工具结果进入后续模型请求。MCP 工具返回的数据也是同一条路径，跨会话的 SendMessage 则会增加另一类显式消息上下文。控制时应优先处理输入和工具边界，例如使用专用工作区、测试凭据、受限命令和脱敏流程，而不是等最终摘要生成后再猜哪些内容曾经外发。

涉及密钥或受监管数据时，不能让真实值进入后台 Agent 启动环境或工具子进程可读取的环境。模型服务自身需要的认证密钥应单独管理。评估本地或自托管模型时，也要同时检查 Skills、MCP 服务和其他工具的网络出口；模型端点部署在本地，并不自动代表整条 Agent 链路没有其他外部连接。

已有架构分析显示 Claude Code 包含权限决策、Hooks、MCP 管理和会话状态等控制环节，但这部分资料分析的是 v2.1.88，可以帮助定位控制面，不能当作当前版本的官方承诺。 对后台 Agent transcript，当前资料没有证明存在跨版本通用的关闭项，实际控制仍应落在四个可验证位置：Agent 能读取什么、能执行什么命令、模型请求发往哪里、提供方如何处理请求。

验证外发范围时，可以先记录环境：

claude --version

同时记录任务类型、显示的模型名称、实际提供方以及是否经过代理。不要只看模型别名，因为别名背后的路由可能发生变化。

然后创建一个只含测试标记的合成文件：

printf '%s\n' 'CANARY_BACKGROUND_7f3a91' > canary-agent-test.txt

在受控环境中启动一个最小后台任务，只要求它读取该文件：

只读取 canary-agent-test.txt，并原样返回其中的标记。

如果受控提供方或网关会记录请求体，就检查标记所在文件及工具输出是否出现在请求中，并分别对比前台、后台、多个后台 Agent 和不同模型路由的请求。如果日志不记录请求体，模型回答中出现标记只能证明模型看到了足以生成答案的那部分内容，不能证明完整 transcript 或全部仓库都被发送。

日志判断也要留意版本差异。例如在 Claude Code 2.1.292 与 gstack 1.91.32 的案例中，fork-subagent schema 会移除 Hook payload 里的 run_in_background 字段，因此缺少这个字段不能证明任务不是后台执行。 同理，资料分别涉及 v2.1.88、v2.1.224 及 2.1.292 等版本，不能把某一个版本的行为直接概括成当前版本行为。

这些控制都有代价：限制工具和命令权限可能降低任务成功率；auto-compact 会压缩上下文并可能丢失细节；切换本地模型可能带来工具调用、上下文窗口和输出质量差异；改变路由还可能影响成本与响应稳定性。因此应按任务风险选择控制强度，而不是承诺一个对所有项目都有效的万能方案。

我的判断是：后台 Agent 的 transcript 外发应被视为需要治理的模型数据边界，而不是一个靠名称或单个开关就能解决的问题；真正可控的是 Agent 能读取什么、请求发往哪里，以及发送方能否被验证。