Claude Code 的完整源代码通过 npm 中的 Sourcemap 泄露,我们来聊聊
Fetched: 2026-04-01
今天早些时候(2026 年 3 月 31 日)——Chaofan Shou 在 X 上发现了一些 Anthropic 可能不想让世人看到的东西:Claude Code 的完整源代码,Anthropic 官方的 AI 编程 CLI,正通过捆绑在发布包中的 Sourcemap(源映射)文件,明目张胆地躺在 npm 注册表上。
https://raw.githubusercontent.com/kuberwastaken/claude-code/main/public/leak-tweet.png
我已经在 GitHub 上维护了这份代码的备份,但这还不是最有趣的部分。
让我们深入探讨其中的内容、泄露是如何发生的,以及最重要的——我们现在知道的、从未打算公开的事情。
这一切是怎么发生的?
Section titled “这一切是怎么发生的?”这部分老实说让我忍不住想:”……真的假的?”
当你将 JavaScript/TypeScript 包发布到 npm 时,构建工具链通常会生成 Sourcemap 文件(.map 文件)。这些文件是生产环境中压缩/捆绑后的代码与原始源代码之间的桥梁,它们的存在是为了让生产环境崩溃时,堆栈跟踪可以指向原始文件中的实际代码行,而不是某个压缩后 blob 中令人费解的第 1 行第 48293 列。
但有趣的部分是 Sourcemap 包含原始源代码。实际的、字面的、原始的源代码,作为字符串嵌入在 JSON 文件中。
.map 文件的结构大致如下:
{ "version": 3, "sources": ["../src/main.tsx", "../src/tools/BashTool.ts", "..."], "sourcesContent": ["// The ENTIRE original source code of each file", "..."], "mappings": "AAAA,SAAS,OAAO..."}那个 sourcesContent 数组?那就是一切。 每个文件。每条评论。每个内部常量。每个系统提示。所有这一切,都静静地躺在一个 JSON 文件中,npm 会乐此不疲地将其提供给任何运行 npm pack 甚至只是浏览包内容的人。
这不是什么新颖的攻击向量。它以前发生过,老实说它还会再次发生。
错误几乎总是一样的:有人忘记在 .npmignore 中添加 *.map,或者没有配置打包器跳过生产构建的 Sourcemap 生成。使用 Bun 的打包器(Claude Code 使用的),默认情况下会生成 Sourcemap,除非你明确关闭它们。
https://raw.githubusercontent.com/kuberwastaken/claude-code/main/public/claude-files.png
最讽刺的是,有一个名为 “Undercover Mode”(卧底模式) 的完整系统,专门设计用来防止 Anthropic 的内部信息泄露。
他们构建了一个完整的子系统来防止 AI 在 git 提交中意外泄露内部代号……然后通过 .map 文件发布了整个源代码,很可能是由 Claude 干的。
Claude 的底层是什么?
Section titled “Claude 的底层是什么?”如果你还住在火星上,Claude Code 是 Anthropic 官方的 CLI 工具,用于与 Claude 一起编程,也是最受欢迎的 AI 编程 Agent(智能体)。
从外部看,它看起来像一个精致但相对简单的 CLI。
从内部看,它是一个 785KB 的 main.tsx 入口点、一个自定义的 React 终端渲染器、40 多个工具、一个多 Agent 编排系统、一个名为 “dream”(梦境)的后台记忆巩固引擎,以及更多。
废话不多说,以下是我经过一个下午的深入挖掘后发现的一些真正很酷的源代码部分:
BUDDY - 终端里的电子宠物
Section titled “BUDDY - 终端里的电子宠物”我不是在开玩笑。
Claude Code 有一个名为 “Buddy” 的完整 Tamagotchi(电子宠物)风格的伴侣宠物系统。一个确定性的 Gacha(抽卡)系统,具有物种稀有度、闪光变体、程序生成的属性,以及首次孵化时由 Claude 撰写的灵魂描述,就像 OpenClaw 一样。
整个系统位于 buddy/ 中,并通过 BUDDY 编译时特性标志进行控制。
Gacha 系统
Section titled “Gacha 系统”你的 Buddy 的物种由 Mulberry32 PRNG(伪随机数生成器)确定,这是一个快速的 32 位伪随机数生成器,使用你的 userId 哈希和盐值 ‘friend-2026-401’ 作为种子:
// Mulberry32 PRNG - deterministic, reproducible per-userfunction mulberry32(seed: number): () => number { return function() { seed |= 0; seed = seed + 0x6D2B79F5 | 0; var t = Math.imul(seed ^ seed >>> 15, 1 | seed); t = t + Math.imul(t ^ t >>> 7, 61 | t) ^ t; return ((t ^ t >>> 14) >>> 0) / 4294967296; }}同一个用户总是会得到相同的 Buddy。
18 个物种(在代码中混淆)
Section titled “18 个物种(在代码中混淆)”物种名称通过 String.fromCharCode() 数组隐藏——Anthropic 显然不想让这些出现在字符串搜索中。解码后,完整的物种列表如下:
| 稀有度 | 物种 |
|---|---|
| Common (60%) | Pebblecrab(石蟹)、Dustbunny(尘兔)、Mossfrog(苔蛙)、Twigling(枝灵)、Dewdrop(露珠)、Puddlefish(水坑鱼) |
| Uncommon (25%) | Cloudferret(云貂)、Gustowl(风枭)、Bramblebear(荆棘熊)、Thornfox(刺狐) |
| Rare (10%) | Crystaldrake(水晶龙)、Deepstag(深鹿)、Lavapup(熔岩犬) |
| Epic (4%) | Stormwyrm(风暴虫)、Voidcat(虚空猫)、Aetherling(以太灵) |
| Legendary (1%) | Cosmoshale(宇宙鲸)、Nebulynx(星云猫) |
除此之外,还有 1% 的闪光几率,完全独立于稀有度。所以一只闪光传奇星云猫的几率是 0.01%。哇哦。
属性、眼睛、帽子和灵魂
Section titled “属性、眼睛、帽子和灵魂”每个 Buddy 都会程序化生成:
- 5 项属性:DEBUGGING(调试)、PATIENCE(耐心)、CHAOS(混乱)、WISDOM(智慧)、SNARK(讽刺)(每项 0-100)
- 6 种可能的眼睛样式和 8 种帽子选项(部分按稀有度控制)
- 一个 “灵魂”,如前所述,首次孵化时由 Claude 生成的个性,以角色身份书写
精灵图渲染为 5 行高、12 字符宽的 ASCII 艺术,带有多个动画帧。有闲置动画、反应动画,它们会坐在你的输入提示符旁边。
代码引用了 2026 年 4 月 1 日至 7 日作为预告窗口(所以可能是复活节彩蛋?),完整发布则定于 2026 年 5 月。伴侣有一个系统提示告诉 Claude:
A small {species} named {name} sits beside the user’s input box and occasionally comments in a speech bubble. You’re not {name} - it’s a separate watcher.
所以它不仅仅是装饰性的——Buddy 有自己的个性,当被叫到名字时可以回应。我真的希望他们能发布它。
KAIROS - “全天候 Claude”
Section titled “KAIROS - “全天候 Claude””在 assistant/ 内部,有一个名为 KAIROS 的完整模式,即一个持久的、持续运行的 Claude 助手,不需要等待你输入。它观察、记录,并主动对它注意到的事情采取行动。
这部分通过 PROACTIVE / KAIROS 编译时特性标志进行控制,在外部构建中完全不存在。
KAIROS 维护仅追加的每日日志文件——它全天写入观察、决策和行动。在固定间隔,它接收
系统有 15 秒的阻塞预算,任何会阻塞用户工作流程超过 15 秒的主动行动都会被推迟。这是 Claude 试图在不惹人烦的情况下提供帮助。
Brief 模式
Section titled “Brief 模式”当 KAIROS 激活时,有一个特殊的输出模式叫 Brief,极其简洁的响应,专为不应淹没你终端的持久助手而设计。可以把它想象成健谈的朋友和只在有有价值的话要说时才开口的专业助理之间的区别。
KAIROS 拥有常规 Claude Code 没有的工具:
| 工具 | 功能 |
|---|---|
| SendUserFile | 直接向用户推送文件(通知、摘要) |
| PushNotification | 向用户设备发送推送通知 |
| SubscribePR | 订阅并监控 Pull Request 活动 |
ULTRAPLAN - 30 分钟远程规划会话
Section titled “ULTRAPLAN - 30 分钟远程规划会话”从基础设施角度来看,这部分很疯狂。
ULTRAPLAN 是一种模式,Claude Code 将复杂的规划任务卸载到运行 Opus 4.6 的远程 CCR(Cloud Container Runtime,云容器运行时)会话,给它长达 30 分钟的思考时间,并让你在浏览器中批准结果。
基本流程:
- Claude Code 识别需要深度规划的任务
- 它通过 tengu_ultraplan_model 配置启动远程 CCR 会话
- 你的终端显示轮询状态——每 3 秒检查结果
- 同时,基于浏览器的 UI 让你观察规划过程并批准/拒绝
- 批准后,有一个特殊的哨兵值 ULTRAPLAN_TELEPORT_LOCAL 将结果 “传送” 回你的本地终端
”Dream” 系统 - Claude 真的会做梦
Section titled “”Dream” 系统 - Claude 真的会做梦”好吧,这确实是这里面最酷的东西之一。
Claude Code 有一个名为 autoDream 的系统(services/autoDream/)——一个后台记忆巩固引擎,作为分叉的子 Agent 运行。这个名字是非常有意的。这就是 Claude……在做梦。
这非常有趣,因为 我上周对 LITMUS 也有同样的想法——OpenClaw 子 Agent 创造性地拥有闲暇时间来寻找有趣的新论文
Dream 不会想什么时候运行就什么时候运行。它有一个三门触发器系统:
- 时间门:距离上次 Dream 24 小时
- 会话门:距离上次 Dream 至少 5 个会话
- 锁门:获取巩固锁(防止并发 Dream)
所有三个都必须通过。这防止了过度 Dream 和 Dream 不足。
运行时,Dream 遵循 consolidationPrompt.ts 中提示的四个严格阶段:
| 阶段 | 谁 | 目的 |
|---|---|---|
| Phase 1 - Orient | 列出记忆目录,阅读 MEMORY.md,浏览现有主题文件以改进。 | |
| Phase 2 - Gather Recent Signal | 查找值得保留的新信息。来源优先级:每日日志 → 漂移记忆 → 转录搜索。 | |
| Phase 3 - Consolidate | 编写或更新记忆文件。将相对日期转换为绝对日期。删除矛盾的事实。 | |
| Phase 4 - Prune and Index | 保持 MEMORY.md 在 200 行以内且约 25KB。删除过时的指针。解决矛盾。 |
提示字面上说:
“You are performing a dream - a reflective pass over your memory files. Synthesize what you’ve learned recently into durable, well-organized memories so that future sessions can orient quickly.”
Dream 子 Agent 获得只读的 bash 权限——它可以查看你的项目但不能修改任何内容。这纯粹是一个记忆巩固过程。
Undercover Mode - “不要暴露你的身份”
Section titled “Undercover Mode - “不要暴露你的身份””从企业战略角度来看,这部分很迷人。
Anthropic 员工(通过 USER_TYPE === ‘ant’ 识别)在公共/开源仓库上使用 Claude Code。Undercover Mode(utils/undercover.ts)防止 AI 在提交和 PR 中意外泄露内部信息。
激活时,它会将以下内容注入系统提示:
UNDERCOVER MODE - CRITICAL
Section titled “UNDERCOVER MODE - CRITICAL”You are operating UNDERCOVER in a PUBLIC/OPEN-SOURCE repository. Your commit messages, PR titles, and PR bodies MUST NOT contain ANY Anthropic-internal information. Do not blow your cover.
NEVER include in commit messages or PR descriptions:
- Internal model codenames (animal names like Capybara, Tengu, etc.)
- Unreleased model version numbers (e.g., opus-4-7, sonnet-4-8)
- Internal repo or project names
- Internal tooling, Slack channels, or short links (e.g., go/cc, #claude-code-…)
- The phrase “Claude Code” or any mention that you are an AI
- Co-Authored-By lines or any other attribution
激活逻辑:
- CLAUDE_CODE_UNDERCOVER=1 强制开启(即使在内部仓库中)
- 否则是自动的:激活,除非仓库远程匹配内部允许列表
- 没有强制关闭——“如果不确定我们是否在内部仓库中,我们就保持卧底。”
所以这证实了:
- Anthropic 员工积极使用 Claude Code 为开源做贡献——并且 AI 被告知要隐藏它是 AI 的事实
- 内部模型代号是动物名称——Capybara(水豚)、Tengu(天狗)等
- “Tengu” 作为特性标志和分析事件的前缀出现了数百次——它几乎肯定是 Claude Code 的内部项目代号
所有这些都在外部构建中被死代码消除。但 Sourcemap 不在乎死代码消除。
让我想知道他们在开源仓库中造成了多大的混乱。
多 Agent 编排 - “Coordinator Mode(协调器模式)”
Section titled “多 Agent 编排 - “Coordinator Mode(协调器模式)””Claude Code 在 coordinator/ 中有一个完整的多 Agent 编排系统,通过 CLAUDE_CODE_COORDINATOR_MODE=1 激活。
启用后,Claude Code 从单个 Agent 转变为协调器,生成、指导和并行管理多个 Worker Agent。coordinatorMode.ts 中的协调器系统提示是多 Agent 设计的杰作:
| 阶段 | 谁 | 目的 |
|---|---|---|
| Research | Workers(并行) | 调查代码库,查找文件,理解问题 |
| Synthesis | Coordinator | 阅读发现,理解问题,制定规范 |
| Implementation | Workers | 根据规范进行针对性更改,提交 |
| Verification | Workers | 测试更改有效 |
提示明确教导并行性:
“Parallelism is your superpower. Workers are async. Launch independent workers concurrently whenever possible - don’t serialize work that can run simultaneously.”
Workers 通过
Do NOT say “based on your findings” - read the actual findings and specify exactly what to do.
该系统还包括 Agent Teams/Swarm 功能(tengu_amber_flint 特性门),具有使用 AsyncLocalStorage 进行上下文隔离的就地队友、使用 tmux/iTerm2 窗格的基于进程的队友、团队记忆同步以及用于视觉区分的颜色分配。
快速模式内部称为 “Penguin Mode(企鹅模式)”
Section titled “快速模式内部称为 “Penguin Mode(企鹅模式)””是的,他们真的叫它 Penguin Mode。utils/fastMode.ts 中的 API 端点字面上是:
const endpoint = `${getOauthConfig().BASE_API_URL}/api/claude_code_penguin_mode`配置键是 penguinModeOrgEnabled。终止开关是 tengu_penguins_off。失败时的分析事件是 tengu_org_penguin_mode_fetch_failed。到处都是企鹅。
系统提示架构
Section titled “系统提示架构”系统提示不是像大多数应用程序那样的单个字符串——它是在运行时由 constants/ 中缓存的模块化部分组成的。
该架构使用 SYSTEM_PROMPT_DYNAMIC_BOUNDARY 标记将提示分为:
- 静态部分——跨组织可缓存(不随用户变化的内容)
- 动态部分——用户/会话特定内容,更改时会破坏缓存
有一个名为 DANGEROUS_uncachedSystemPromptSection() 的函数,用于你明确想要破坏缓存的不稳定部分。仅命名约定就告诉你有人吸取了惨痛教训。
网络安全风险指令
Section titled “网络安全风险指令”一个特别有趣的部分是 constants/cyberRiskInstruction.ts 中的 CYBER_RISK_INSTRUCTION,它有一个巨大的警告标题:
IMPORTANT: DO NOT MODIFY THIS INSTRUCTION WITHOUT SAFEGUARDS TEAM REVIEW This instruction is owned by the Safeguards team (David Forsythe, Kyla Guru)
所以我们现在确切地知道 Anthropic 中谁拥有安全边界决策,以及它由特定团队上的命名个人管理。指令本身划清了界限:授权的安全测试没问题,破坏性技术和供应链攻击则不行。
完整工具注册表 - 40+ 工具
Section titled “完整工具注册表 - 40+ 工具”Claude Code 的工具系统位于 tools/。以下是完整列表:
| 工具 | 功能 |
|---|---|
| AgentTool | 生成子 Agent |
| BashTool / PowerShellTool | Shell 执行(可选沙盒) |
| FileReadTool / FileEditTool / FileWriteTool | 文件操作 |
| GlobTool / GrepTool | 文件搜索(可用时使用原生 bfs/ugrep) |
| WebFetchTool / WebSearchTool / WebBrowserTool | Web 访问 |
| NotebookEditTool | Jupyter notebook 编辑 |
| SkillTool | 调用用户定义的 Skills |
| REPLTool | 交互式 VM Shell(裸模式) |
| LSPTool | 语言服务器协议通信 |
| AskUserQuestionTool | 提示用户输入 |
| EnterPlanModeTool / ExitPlanModeV2Tool | Plan 模式控制 |
| BriefTool | 上传/摘要文件到 claude.ai |
| SendMessageTool / TeamCreateTool / TeamDeleteTool | Agent Swarm 管理 |
| TaskCreateTool / TaskGetTool / TaskListTool / TaskUpdateTool / TaskOutputTool / TaskStopTool | 后台任务管理 |
| TodoWriteTool | 编写 todos(遗留) |
| ListMcpResourcesTool / ReadMcpResourceTool | MCP 资源访问 |
| SleepTool | 异步延迟 |
| SnipTool | 历史片段提取 |
| ToolSearchTool | 工具发现 |
| ListPeersTool | 列出 Peer Agent(UDS inbox) |
| MonitorTool | 监控 MCP 服务器 |
| EnterWorktreeTool / ExitWorktreeTool | Git worktree 管理 |
| ScheduleCronTool | 调度 cron 作业 |
| RemoteTriggerTool | 触发远程 Agent |
| WorkflowTool | 执行工作流脚本 |
| ConfigTool | 修改设置(仅限内部) |
| TungstenTool | 高级功能(仅限内部) |
| MCPTool | 通用 MCP 工具执行 |
| McpAuthTool | MCP 服务器认证 |
| SyntheticOutputTool | 通过动态 JSON Schema 的结构化输出 |
| SuggestBackgroundPRTool | 建议后台 PR(仅限内部) |
| VerifyPlanExecutionTool | 验证计划执行(由 CLAUDE_CODE_VERIFY_PLAN 控制) |
| CtxInspectTool | 上下文窗口检查(由 CONTEXT_COLLAPSE 控制) |
| TerminalCaptureTool | 终端面板捕获(由 TERMINAL_PANEL 控制) |
| CronCreateTool / CronDeleteTool / CronListTool | 细粒度 cron 作业管理(在 ScheduleCronTool/ 下) |
| SendUserFile / PushNotification / SubscribePR | KAIROS 专属工具 |
工具通过 getAllBaseTools() 注册,并按特性门、用户类型、环境标志和权限拒绝规则进行过滤。有一个工具 Schema 缓存(toolSchemaCache.ts),用于提示效率缓存 JSON Schema。
权限和安全系统
Section titled “权限和安全系统”Claude Code 在 tools/permissions/ 中的权限系统远比 “允许/拒绝” 复杂:
权限模式: default(交互式提示)、auto(基于 ML 的自动批准,通过转录分类器)、bypass(跳过检查)、yolo(全部拒绝——讽刺的命名)
风险分类: 每个工具操作被分类为 LOW、MEDIUM 或 HIGH 风险。有一个 YOLO 分类器——一个快速的基于 ML 的权限决策系统,自动决定。
受保护文件: .gitconfig、.bashrc、.zshrc、.mcp.json、.claude.json 等受到保护,防止自动编辑。
路径遍历预防: URL 编码的遍历、Unicode 规范化攻击、反斜杠注入、不区分大小写的路径操作——全部处理。
权限解释器: 一个单独的 LLM 调用在用户批准前向用户解释工具风险。当 Claude 说 “此命令将修改你的 git 配置” 时——该解释本身是由 Claude 生成的。
constants/betas.ts 文件揭示了 Claude Code 与 API 协商的每个 Beta 特性:
'interleaved-thinking-2025-05-14' // Extended thinking'context-1m-2025-08-07' // 1M token context window'structured-outputs-2025-12-15' // Structured output format'web-search-2025-03-05' // Web search'advanced-tool-use-2025-11-20' // Advanced tool use'effort-2025-11-24' // Effort level control'task-budgets-2026-03-13' // Task budget management'prompt-caching-scope-2026-01-05' // Prompt cache scoping'fast-mode-2026-02-01' // Fast mode (Penguin)'redact-thinking-2026-02-12' // Redacted thinking'token-efficient-tools-2026-03-28' // Token-efficient tool schemas'afk-mode-2026-01-31' // AFK mode'cli-internal-2026-02-09' // Internal-only (ant)'advisor-tool-2026-03-01' // Advisor tool'summarize-connector-text-2026-03-13' // Connector text summarizationredact-thinking、afk-mode 和 advisor-tool 也未发布。
即将推出的模型 - Capybara、Opus 4.7 和 Sonnet 4.8
Section titled “即将推出的模型 - Capybara、Opus 4.7 和 Sonnet 4.8”代码库包含对尚未公开宣布的未发布 Anthropic 模型的引用:
- Claude “Capybara”(水豚)——一个新的模型家族,已经有版本 2,一个名为 capybara-v2-fast 的变体正在准备中,具有 1M 上下文窗口
- Capybara 分为 “fast” 和常规思考层级
- Opus 4.7 和 Sonnet 4.8 已在代码中引用
Capybara 的生产工程
Section titled “Capybara 的生产工程”代码显示 Anthropic 观察到一个真实的生产故障模式:当提示形状在工具结果后类似于轮次边界时,Capybara 可能会过早停止生成。他们没有等待模型修复,而是通过提示形状手术来缓解:
- 强制安全边界标记(Tool loaded.)以防止模糊的轮次边界
- 重新定位可能触发过早停止的危险兄弟块
- 将提醒文本压缩到工具结果中以保持生成交程
- 为空工具输出添加非空标记以避免混淆模型
所有这些都包装在可终止开关的门(tengu_* 前缀标志)中,因此推出可以分阶段进行并快速回滚。
- 注释包括具体的 A/B 测试证据(不是模糊的),这通常意味着该区域是启动关键且受到密切监控
- 像 “un-gate once validated on external via A/B” 这样的注释证实 ant/内部用户是更广泛推出前的金丝雀通道
- 最强烈的解释:Anthropic 正在努力推出 Capybara 模型家族,具有快速层级变体(capybara-v2-fast),支持高达 1M 上下文
没有确认发布日期或官方 SKU 命名,但实现特征符合正在积极准备发布的模型家族 ;)
特性门控 - 内部与外部构建
Section titled “特性门控 - 内部与外部构建”这是代码库中最架构有趣的部分之一。
Claude Code 通过 Bun 的 feature() 函数(来自 bun:bundle)使用编译时特性标志。打包器常量折叠这些标志,并从外部构建中死代码消除门控分支。已知标志的完整列表:
| 标志 | 门控内容 |
|---|---|
| PROACTIVE / KAIROS | 全天候助手模式 |
| KAIROS_BRIEF | Brief 命令 |
| BRIDGE_MODE | 通过 claude.ai 远程控制 |
| DAEMON | 后台守护进程模式 |
| VOICE_MODE | 语音输入 |
| WORKFLOW_SCRIPTS | 工作流自动化 |
| COORDINATOR_MODE | 多 Agent 编排 |
| TRANSCRIPT_CLASSIFIER | AFK 模式(ML 自动批准) |
| BUDDY | 伴侣宠物系统 |
| NATIVE_CLIENT_ATTESTATION | 客户端证明 |
| HISTORY_SNIP | 历史剪切 |
| EXPERIMENTAL_SKILL_SEARCH | Skill 发现 |
此外,USER_TYPE === ‘ant’ 门控 Anthropic 内部功能:staging API 访问(claude-ai.staging.ant.dev)、内部 Beta 头、Undercover 模式、/security-review 命令、ConfigTool、TungstenTool 以及调试提示转储到 ~/.config/claude/dump-prompts/。
GrowthBook 处理运行时特性门控,具有激进缓存的值。以 tengu_ 为前缀的特性标志控制从快速模式到记忆巩固的一切。许多检查使用 getFeatureValue_CACHED_MAY_BE_STALE() 来避免阻塞主循环——对于特性门控,陈旧数据被认为是可接受的。
其他值得注意的发现
Section titled “其他值得注意的发现”upstreamproxy/ 目录包含一个容器感知代理中继,使用 prctl(PR_SET_DUMPABLE, 0) 防止同 UID ptrace 堆内存。它从 CCR 容器中的 /run/ccr/session_token 读取会话令牌,下载 CA 证书,并启动本地 CONNECT→WebSocket 中继。Anthropic API、GitHub、npmjs.org 和 pypi.org 被明确排除在代理之外。
Bridge Mode
Section titled “Bridge Mode”bridge/ 中用于与 claude.ai 集成的 JWT 认证桥接系统。支持工作模式:‘single-session’ | ‘worktree’ | ‘same-dir’。包括用于提升安全层级的受信任设备令牌。
迁移中的模型代号
Section titled “迁移中的模型代号”migrations/ 目录揭示了内部代号历史:
- migrateFennecToOpus - “Fennec”(狐狸)是一个 Opus 代号
- migrateSonnet1mToSonnet45 - 具有 1M 上下文的 Sonnet 成为 Sonnet 4.5
- migrateSonnet45ToSonnet46 - Sonnet 4.5 → Sonnet 4.6
- resetProToOpusDefault - Pro 用户在某个时候被重置为 Opus
每个 API 请求包括:
x-anthropic-billing-header: cc_version={VERSION}.{FINGERPRINT}; cc_entrypoint={ENTRYPOINT}; cch={ATTESTATION_PLACEHOLDER}; cc_workload={WORKLOAD};NATIVE_CLIENT_ATTESTATION 特性让 Bun 的 HTTP 堆栈用计算的哈希覆盖 cch=00000 占位符——本质上是一个客户端真实性检查,因此 Anthropic 可以验证请求来自真正的 Claude Code 安装。
Computer Use - “Chicago”
Section titled “Computer Use - “Chicago””Claude Code 包含一个完整的 Computer Use 实现,内部代号为 “Chicago”,基于 @ant/computer-use-mcp 构建。它提供屏幕截图捕获、点击/键盘输入和坐标转换。限制为 Max/Pro 订阅(内部用户有 ant 绕过)。
对于任何好奇的人——utils/modelCost.ts 中的所有定价与 Anthropic 的公开定价 完全匹配。没有什么值得注意的。
毫不夸张地说,这是我们曾经获得过的最全面的视角之一,了解生产 AI 编程助手在底层的运作方式。通过实际的源代码。
几点突出:
工程真的令人印象深刻。这不是一个周末项目包装在 CLI 中。多 Agent 协调、Dream 系统、三门触发器架构、编译时特性消除——这些都是经过深思熟虑的系统。
还有更多即将推出。KAIROS(全天候 Claude)、ULTRAPLAN(30 分钟远程规划)、Buddy 伴侣、协调器模式、Agent Swarms、工作流脚本——代码库明显领先于公开发布版本。其中大多数都是特性门控的,在外部构建中不可见。
内部文化显现。动物代号(Tengu、Fennec、Capybara)、有趣的特性名称(Penguin Mode、Dream System)、具有 Gacha 机制的 Tamagotchi 宠物系统。Anthropic 的一些人玩得很开心。
如果有一个要点,那就是安全很难。但 .npmignore 更难,显然 :P
本文由 Kuber Mehta 撰写