Claude Code 源码泄露：封号风险、当前模型和帐号逻辑说明（2026）

Claude Code 在 2026 年 3 月确实发生过源码暴露。Anthropic 对外的表述是：这是一次 release packaging mistake，不是外部 breach，而且没有暴露敏感客户数据或凭证。真正值得读者搞清楚的，不是镜像仓库里到底出现了多少隐藏字符串，而是 Anthropic 现在公开文档里仍然怎么写 bans、当前公开模型，以及 Claude 订阅、Console 账号和 API Key 计费到底怎么分。截止 2026 年 4 月 1 日，Anthropic 的公开帮助中心仍然把重点放在三件事上：封号属于 policy / terms 范畴，Claude Code 的公开高端模型仍是 Sonnet 4.6 和 Opus 4.6，而 Claude 订阅、Console 账号、API Key 计费是彼此独立的路径。

“

证据说明：本文基于 2026 年 4 月 1 日核对的 Anthropic 帮助中心、release notes、政策页面与产品页面，同时参考 Axios 3 月 31 日报道、Fortune 3 月 26 日报道，以及对当前 @anthropic-ai/claude-code 2.1.89 npm 包的直接检查。

TL;DR

• 是的，Claude Code 的源码暴露是真事。Axios 引述 Anthropic 说，早前某个 Claude Code 发布包确实带出了内部源码。
• Anthropic 同时表示，这次事件没有暴露敏感客户数据或凭证。
• Anthropic 公开的 Safeguards Warnings and Appeals 帮助页写明，账号可能因为反复违反 Usage Policy、从不支持地区创建账号、或违反 Terms 而被封；它并没有写“你看了泄露内容就会被封”。
• 3 月 26 日的 Fortune 报道和 3 月 31 日的 Axios 报道不是同一件事。前者是公开可访问数据存储暴露，后者是 Claude Code 发布打包错误。
• 目前 Claude Code 的公开高端模型现实仍然是 Sonnet 4.6 和 Opus 4.6。4.5 系列里有些旧模型仍可配置，但 Opus 4 与 4.1 已在 2026 年 1 月 16 日从 Claude 和 Claude Code 中移除。
• Claude 账号和 Console 账号可以使用同一个邮箱，但依然是独立系统；在 Claude Code 里，如果环境变量里有 ANTHROPIC_API_KEY，它会优先于订阅登录用于计费。

3 月 31 日到底泄露了什么，没有泄露什么

这类话题最容易出错的地方，是把不同事件压成一句“Anthropic 全泄了”。实际上，3 月底至少有两条不同的故事线，社交媒体后来把它们搅在了一起。

3 月 26 日，Fortune 报道 的重点，是 Anthropic 某些内部材料似乎被放在了公开可访问的数据存储中，里面包括未发布模型相关资料、活动材料和其他未公开资产。Anthropic 在那篇报道里承认，它确实正在和 early-access customers 测试更强的新模型，但那条报道的核心是“更广义的内部资料暴露”。

3 月 31 日，Axios 报道 的重点则更贴近开发者：Anthropic 向 Axios 表示，较早前某个 Claude Code release 里错误打包进了内部源码。这里最重要的不是“泄露”两个字本身，而是 Anthropic 给出的边界定义。它一方面确认了“内部源码暴露”是真事，不是纯粹的标题党；另一方面又把边界收窄成“打包错误”，并明确说没有客户数据或凭证暴露。

这和很多中文帖子里那种“一句带过”的说法并不一样。内部源码暴露 是严重问题，但它并不自动等于 客户数据泄露、模型权重泄露，或者 用户密钥泄露。如果把这些全压成一句“Anthropic 被爆库了”，读者就无法据此做任何准确判断。

还有一个实际层面的细节，大多数转述都没有提：当前公开 npm 包的状态，和最初那个出问题的发布，不一定还是同一个面貌。我在 2026 年 4 月 1 日直接检查了当前 @anthropic-ai/claude-code 2.1.89 包：tarball 现在是一个单独打包的 cli.js，包列表里没有单独 .map 文件，cli.js 末尾也没有 sourceMappingURL= footer。这个事实不会否定更早的暴露曾经发生过，但它会改变读者今天该采取的操作判断。更准确的说法不是“npm 现在还在公开完整源码映射”，而是“Anthropic 之前确实发过一个有问题的包，但今天你能拉到的当前包，已经不是那个最直观的泄露形态”。

因此，这件事最稳妥的认知方式应该拆成三层：

• Anthropic 公开确认的：Claude Code 发布里曾错误带出内部源码；没有客户数据或凭证暴露。
• 当前包状态确认的：今天公开 npm 包已经不再呈现最简单那种“source map 仍外挂”的形态。
• 仍然不是公开产品合同的：镜像仓库里出现的 roadmap 提示、隐藏 feature 名字、以及各种未发布功能猜测。

如果你先把这一层弄清楚，后面的 ban 传言、模型讨论和账号逻辑就会清晰很多。

Anthropic 公开写过的封号规则是什么

关于“会不会被封”，最值得看的不是论坛转述，而是 Anthropic 自己的 Safeguards Warnings and Appeals 页面。那页明确写了三类公开 suspension reasons：反复违反 Usage Policy、从不支持地区创建账号、以及违反 Terms of Service。它还写明，在某些情况下会先发 warning，并给出公开 appeal 表单，供用户在觉得自己被误封时申诉。

这页真正重要的地方，在于它说了什么，也在于它没说什么。它给出了 Anthropic 公开承认的 enforcement surface，但它没有写“阅读泄露内容”“点开镜像仓库”“看了新闻报道”本身就是独立的封号触发条件。所以，截止目前最稳妥的公开答案只能写得很窄：Anthropic 公开文档把封号放在 policy / terms 范畴里，但没有公开写过“仅仅看了泄露就会被封”。

这并不等于所有围绕暴露材料的行为都没有风险。Anthropic 的 Responsible Disclosure Policy 对 good-faith security research 的要求写得很清楚：避免 exfiltrate、download、retain 数据；不要在未协调前公开披露漏洞细节；不要超出“证明漏洞存在所需的最小范围”去继续利用。那份政策写给安全研究，而不是普通 Claude 用户，但它仍然能说明 Anthropic 在“暴露内部系统材料如何处理”这件事上的公开态度。

基于这些来源可以做一个明确标注为推断的结论：Anthropic 的公开文档不支持“只要你看了泄露内容就会自动被封”这种广泛流传的说法。但如果你的行为不是“我看了新闻”，而更接近“我保留、利用、扩散了暴露材料”，你就显然更接近 Anthropic 公开 policies 和 terms 真正在意的那类行为边界。

这个中间答案，比两种极端都更有用。完全不会有事 过于武断。看一眼就封号 也没有公开文档支撑。当前公开证据支持的，是一个更窄、更实用的说法：封号逻辑仍然是 policy-based，而不是 rumor-based；warnings 和 appeals 是公开存在的；Anthropic 没有公开写出一个“阅读即封”的简单规则。

对普通用户来说，操作层面的结论其实很朴素：

• 风险判断优先以 Anthropic 公开 help-center 和 policy 页面为准
• 不要把暴露出来的内部资产当成“官方允许使用的 surface”
• 如果真的被误封，直接走公开 appeal path，而不是只依赖社区传言

Claude Code 当前公开模型到底是什么

泄露讨论还顺手带回了很多过时的模型认知。这个问题很重要，因为很多人会拿 leak 截图里的名字，去替代当前真正支持的 Claude Code 模型列表。

Anthropic 当前的 Claude Code model configuration 页面列出的支持模型是：

• Sonnet 4.6：claude-sonnet-4-6
• Opus 4.6：claude-opus-4-6
• Opus 4.5：claude-opus-4-5-20251101
• Haiku 4.5：claude-haiku-4-5-20251001
• Sonnet 4.5：claude-sonnet-4-5-20250929

这个列表至少说明两件事。第一，当前 Claude Code 的公开高端现实，仍然是 Sonnet 4.6 和 Opus 4.6。第二，并不是所有 4.5 系列都已消失，所以“最新默认模型”和“仍旧可配置模型”不是一回事。

Anthropic 的 release notes 把时间线写得更清楚：

• 2026 年 1 月 16 日：Opus 4 与 4.1 从 Claude 和 Claude Code 移除
• 2026 年 2 月 5 日：Claude Opus 4.6 发布
• 2026 年 2 月 17 日：Claude Sonnet 4.6 发布

所以，如果你现在看到帖子还把 Opus 4、4.1 当成 Claude Code 的默认旗舰，那就是过时信息。如果有人把 leak 里出现的新名字直接写成“现已公开可用模型”，那也是不准确的。

这里还有两个对实际决策很重要的细节。

第一个是访问边界。Anthropic 的 model configuration 页面明确写着：在 Pro 方案下使用 Claude Code，如果你想用 Opus，需要先开启并购买 extra usage。这个事实对普通读者比任何 roadmap 猜测都更重要，因为它直接决定你现在是不是“理论上知道有 Opus 4.6”，还是“合同上真的能稳定用 Opus 4.6”。如果你想进一步看 plan 差异，可以读我们的 Claude Code Pro vs Max 指南。

第二个是长上下文。Anthropic 的 Claude Code FAQ 现在写明：对 Max、Team 和 Enterprise 用户，Opus 4.6 在 Claude Code 中已包含 1M context。这个细节再次说明，真正改变使用决策的，仍然是 help-center 上写出的当前合同，而不是 leak 里任何“看起来更强”的代号。

目前最短、最准确的模型结论是：

• 如果你要看当前主线 public model，先看 Sonnet 4.6。
• 如果你需要 Anthropic 现阶段公开最强推理路径，并且你的 plan 或 billing 支持，就看 Opus 4.6。
• 4.5 系列更适合被视为“仍支持的旧代路线”，而不是今天的前沿主线。
• 泄露里出现的新名字，在没有进入 help-center、release notes 或 pricing 之前，都不应当被写成公开合同。

Claude 账号、Console 账号和 API Key 在 Claude Code 里怎么分工

这部分其实比 leak 本身更容易让用户踩坑，因为很多人把“同一个邮箱”误以为“同一套 billing system”。

Anthropic 的帮助中心有一条非常短、但非常关键的回答：Can I have a Claude account and a Console account?。答案很直接：可以，而且可以用同一个邮箱，但两者独立运行。只要把这句真正理解清楚，很多关于 internal account logic 的玄学就自动消失了。

Claude 账号是消费端或工作端的产品表层：Free、Pro、Max、Team、Enterprise 这些计划都属于 Claude 这一侧。Console 账号则是 API 侧：组织、API 计费、rate limits、API keys、开发者控制项，都属于 Console 一侧。同一个人当然可以同时拥有它们，但这不代表它们是同一个预算池。

Anthropic 的 Using Claude Code with your Pro or Max plan 页面把消费端合同写得很清楚：如果你用 Claude 订阅的同一套登录凭证登录 Claude Code，就会走对应 plan 的使用额度。而且 Claude 与 Claude Code 的使用量属于共享 usage pool，不是分离的两桶。

最容易被忽略的坑，在 Anthropic 的 Managing API key environment variables in Claude Code 页面里写得非常直白：Claude Code 会优先使用环境变量中的 API key，而不是你已登录的订阅身份。也就是说，如果 shell 里存在 ANTHROPIC_API_KEY，Claude Code 就会按这个 key 所属 API 账号计费，即使你同时已经用 Claude 订阅登录了 Claude Code。

可以把这套逻辑理解成三条平行路径：

还有两个常见但很有实际价值的补充点。

第一，Anthropic 在 Pro/Max 那篇文章里明确写到：如果你当前是用 Claude Console PAYG 登录到 Claude Code，可以通过 /login 切回订阅计划。这不是小技巧，而是 Anthropic 官方提供的“在两套系统之间切换”的正确方式。

第二，Anthropic 的 Claude Code FAQ 对组织级逻辑也给了公开答案。FAQ 写到：如果你是 Console 用户，可以把人直接加到 Console 组织里，给 Claude Code User 或 Developer 角色，然后让用户在 Claude Code 中通过 /login 选择对应 Console 账号。FAQ 还写到，如果你本该有 Team 或 Enterprise 权限，却在 Claude Code 看到“需要 Max 或 Pro 才能连接”的报错，常见原因是你选错了登录路径。

所以，真正值得记住的账号逻辑，其实已经足够具体：

• 同一邮箱可以同时拥有 Claude 账号和 Console 账号
• 订阅使用量和 API 计费不是一套系统
• ANTHROPIC_API_KEY 会覆盖订阅登录的计费路径
• /status 和 /login 是排查当前身份路径的第一步

如果你真正需要的是稳定的 API contract，而不是 Claude Code 订阅工作流，那就把它当成 API 问题来处理，而不是试图把 Claude 订阅登录“拧”成生产级 API 通道。直接走 Anthropic Console 或其他支持的 API 路线，会比在订阅工作流里找缝隙更可靠。

泄露里出现的“内部细节”，哪些现在不该拿来做决策

这部分最容易让人把“有趣”误判成“可行动”。

是的，bundle 检查和 leak coverage 会暴露一些真实信号。就连当前公开的 Claude Code 打包文件里，仍然能看到一些和公开流程有关的字符串，比如 --console、--claudeai、/login、setup-token、--enable-auto-mode 等。有些已经公开文档化，有些还更接近实现细节。

但“代码里有这个字符串”和“你现在有这个公开 entitlement”不是一回事；“leak 里看到了 feature 名字”和“Anthropic 已经把它作为当前产品合同对外发布”更不是一回事。最典型的例子就是 Auto mode。你当然可以在代码、changelog 或 leak 讨论里看到相关名字，但它是不是当前对你开放，仍然要看 Anthropic 公开写出的 plan、模型、管理员开关和 surface 限制。如果你想看当前公开的权限模式边界，可以读我们的 Claude Code Auto mode 指南。

这条规则其实适用于所有“泄露里发现的内部细节”：

• 如果 Anthropic 已经把它写进当前 help-center、release notes、pricing 或产品页，那它才是你可以依赖的公开合同。
• 如果唯一证据是 leak、feature flag 名、镜像仓库或反编译字符串，它最多是 roadmap signal，不是你现在能据此采购、迁移、承诺给团队的 public contract。
• 如果 leak 里的暗示和 help-center 的当前写法冲突，优先相信 help-center，直到 Anthropic 正式更新文档。

这不是保守，而是唯一能避免错误决策的做法。否则你很容易因为“看见了内部名字”，就去买错计划、选错登录路径，或者向团队错误承诺某个功能已经公开可用。

现在应该怎么做

如果你是普通 Claude Code 用户，接下来的动作不应该是继续追 leak 细节，而应该是把自己的现实使用路径校准清楚：

1. 更新 Claude Code，不要默认你今天拉到的 npm 包仍然等于最初那个出问题的发布。
2. 运行 /status，确认自己当前到底是在用订阅登录，还是已经被 API key 覆盖了计费路径。
3. 如果你的本意是消耗 plan usage，先检查 ANTHROPIC_API_KEY 是否还留在环境变量里。
4. 模型选择以 Anthropic 当前支持模型列表为准，而不是 leak 帖子里的命名。

如果你真正担心的是封号风险，那就把注意力拉回 Anthropic 的公开规则。当前公开文档支持的是一个基于 policy 和 terms 的 enforcement 视角，而不是一个基于 rumor 的“看一眼就封”视角。如果你认为账号被误封，Anthropic 公开提供了 appeals 路径，这才是可执行的官方流程。

如果你是团队管理员或技术负责人，这次事件最值得你吸收的，不是“Anthropic 内部还有哪些隐藏功能”，而是你自己的团队很可能已经对登录路径、模型可用性和计费优先级存在长期误解。先把这些基础合同讲清楚，再谈更复杂的路线。

如果你是安全研究者或高阶用户，那么最该守住的是分类边界：了解暴露事实、按 Anthropic 公开产品合同正常使用服务、以及把暴露内部资产当成“可自由操作 surface”，这是三件完全不同的事。第一件很正常，第二件是必须的，第三件才是最容易把自己带进麻烦区的地方。

这件事最有价值的结论，其实也最不戏剧化：泄露是真的，但当前 Claude Code 的公开合同依然比传言简单得多。Anthropic 的帮助中心已经把当前支持模型、账号分流、计费优先级和公开封号边界写得足够清楚。先按这些真实合同做判断，绝大多数恐慌都会自然消失。