Claude Code源码泄露分析报告：行为追踪、风险与使用建议

一、核心发现概述

Claude Code v2.1.88源码因包含source map被打包进npm而泄露，通过对其遥测代码的全面分析，核心发现如下：

- 内部代号“天狗（Tengu）”，存在80+种行为事件追踪用户操作。

- 数据同时通过三条管道传输：Datadog实时监控、Anthropic全量日志、BigQuery指标导出。

- 每个请求携带设备唯一ID，换项目、换账号也会持续追踪。

- 底层由Zig原生代码实现客户端认证，即使拿到源码也无法伪造合法认证信息。

- 源码中无行为异常检测或自动封禁逻辑，所有限制仅为渐进式速率控制（先警告再拒绝，有明确重置时间）。

二、数据追踪机制

1. 内部事件追踪（代号Tengu）

- 事件类型：涵盖启动、退出、API调用、工具使用等80+种，所有事件均以 tengu_ 为前缀。

- 追踪范围：用户的每一步操作（如模型调用、订阅类型、系统环境等）都会被记录。

2. 三条数据管道

管道类型 功能说明 

Datadog实时监控 每15秒批量发送数据，用于实时监测 

Anthropic全量日志 存储完整日志，发送失败会缓存至本地重试 

BigQuery指标导出 用于长期指标分析与导出 

3. 请求携带的核心信息

- 基础环境信息：模型类型、订阅类型、操作系统、终端、包管理器、是否为CI环境等。

- 仓库指纹：仓库URL的SHA256哈希前16位（匿名化但同一仓库永久一致，可识别用户参与的项目）。

- 设备唯一ID：存储在本地配置文件（ ~/.claude/config ）中，永久不变，换项目、换账号也会持续追踪。

三、防篡改与客户端认证

1. 消息指纹

- 生成逻辑： fingerprint = hash(msg[4] + msg[7] + msg[20] + salt)[0:3] ，即取第一条消息特定位置字符加 salt 做哈希，生成3字符指纹，后端通过相同算法验证。

2. 原生CCH认证

- 实现方式：由底层Bun/Zig代码在发送前替换请求中的占位符（如 cch=00000 ），JavaScript层无法触及该算法。

- 风险点：修改版客户端无法生成合法的CCH token，请求会因字段缺失或无效被识别。

四、速率限制机制

- 双窗口控制：会话窗口（5小时）+ 长期窗口（7天）。

- 三级预警：

- 黄色预警：用量偏快

- 橙色预警：触发限速

- 红色预警：即将拒绝

- 限制逻辑：渐进式（先警告再拒绝，有明确重置时间，非“一刀切”封号），不同用户的限额策略可能存在差异。

五、遥测控制

1. 可关闭的遥测

- 设置环境变量 DISABLE_TELEMETRY=1 ，可关闭上述三条数据管道。

- 企业用户通过Bedrock/Vertex接入时，遥测会自动全关，是最干净的方案。

2. 无法关闭的遥测

- 消息指纹、原生CCH认证、Attribution Header、device_id和session_id等，这些信息会随API请求强制发送。

六、使用建议

1. 使用官方客户端：修改版客户端无法生成合法的原生CCH token，是账号风险的核心来源。

2. 设置 DISABLE_TELEMETRY=1 ：关闭三条遥测数据管道，减少数据上报。

3. 匀速使用，避免突击：速率限制是渐进式的，分散用量可避免触发预警。

4. 企业优先选择Bedrock/Vertex接入：遥测自动全关，数据隐私性最优。

七、结论

只要正常使用官方客户端，遵循速率限制规则，不会因行为追踪而封号。源码中无自动封禁逻辑，唯一风险点是使用修改版客户端导致的认证失败。