# Claude Code 源码泄露：封号风险、当前模型和帐号逻辑说明（2026） > Claude Code 在 2026 年 3 月确实发生过源码暴露。Anthropic 对 Axios 表示，这是一场发布打包错误，不是外部入侵，而且没有暴露客户数据或凭证。真正更难的部分，是把这件事和真实封号边界、当前模型合同，以及 Claude/Console 账号逻辑拆开。 - URL: https://blog.laozhang.ai/zh/posts/claude-code-source-leak-ban-policy - Published: 2026-04-01 - Updated: 2026-04-01 - Author: AI Free API Team (https://blog.laozhang.ai/zh/about) - Category: Claude Code - Tags: Claude Code, Anthropic, 源码泄露, 封号策略, Claude 模型, 开发者工具 --- 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 日报道](https://www.axios.com/2026/03/31/anthropic-leaked-source-code-ai)、[Fortune 3 月 26 日报道](https://fortune.com/2026/03/26/anthropic-leaked-unreleased-model-exclusive-event-security-issues-cybersecurity-unsecured-data-store/)，以及对当前 `@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 而被封；它并没有写“你看了泄露内容就会被封”。 - 同一页现在还写明，Anthropic 正在为 Opus 4.6 推出 real-time cyber safeguards。它会拦截明显恶意的网络安全请求，也可能拦住部分双用途漏洞发现任务；这和“账号直接被封”不是一回事。 - 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 报道](https://fortune.com/2026/03/26/anthropic-leaked-unreleased-model-exclusive-event-security-issues-cybersecurity-unsecured-data-store/) 的重点，是 Anthropic 某些内部材料似乎被放在了公开可访问的数据存储中，里面包括未发布模型相关资料、活动材料和其他未公开资产。Anthropic 在那篇报道里承认，它确实正在和 early-access customers 测试更强的新模型，但那条报道的核心是“更广义的内部资料暴露”。 3 月 31 日，[Axios 报道](https://www.axios.com/2026/03/31/anthropic-leaked-source-code-ai) 的重点则更贴近开发者：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 之前确实发过一个有问题的包，但今天你能拉到的当前包，已经不是那个最直观的泄露形态”。 ![Claude Code 泄露事件中的官方确认、报道内容与未知边界](https://blog.laozhang.ai/posts/zh/claude-code-source-leak-ban-policy/img/evidence-boundary.jpg) 因此，这件事最稳妥的认知方式应该拆成三层： - Anthropic 公开确认的：Claude Code 发布里曾错误带出内部源码；没有客户数据或凭证暴露。 - 当前包状态确认的：今天公开 npm 包已经不再呈现最简单那种“source map 仍外挂”的形态。 - 仍然不是公开产品合同的：镜像仓库里出现的 roadmap 提示、隐藏 feature 名字、以及各种未发布功能猜测。 如果你先把这一层弄清楚，后面的封号判断、模型选择和账号逻辑就会清晰很多。 ## Anthropic 公开写过的封号规则是什么 关于“会不会被封”，最该先看的就是 Anthropic 自己的 [Safeguards Warnings and Appeals](https://support.claude.com/en/articles/8241253-safeguards-warnings-and-appeals) 页面。那页明确写了三类公开 suspension reasons：反复违反 Usage Policy、从不支持地区创建账号、以及违反 Terms of Service。它还写明，在某些情况下会先发 warning，并给出公开 appeal 表单，供用户在觉得自己被误封时申诉。 截至 2026 年 4 月 1 日更新的版本，同一页还新增了另一层信息：Anthropic 正在为 Claude Opus 4.6 推出 real-time cyber safeguards。官方写法是，这些 safeguards 会拦截明显恶意的网络安全活动，例如大规模数据 exfiltration 或勒索软件开发，而且连某些双用途的 vulnerability discovery 工作也可能被拦住。这和 account suspension 不是同一层规则，但它很重要，因为外部讨论经常把“请求被拦截”和“账号被封”压成一件事。 这页真正重要的地方，在于它说了什么，也在于它没说什么。它给出了 Anthropic 公开承认的 enforcement surface，但它没有写“阅读泄露内容”“点开镜像仓库”“看了新闻报道”本身就是独立的封号触发条件。所以，截止目前最稳妥的公开答案仍然只能写得很窄：Anthropic 公开文档同时写了 policy / terms 层面的 suspension reasons，以及某些网络安全请求会被实时拦截，但它没有公开写过“仅仅看了泄露就会被封”。 这并不等于所有围绕暴露材料的行为都没有风险。Anthropic 的 [Responsible Disclosure Policy](https://www.anthropic.com/responsible-disclosure-policy) 对 good-faith security research 的要求写得很清楚：避免 exfiltrate、download、retain 数据；不要在未协调前公开披露漏洞细节；不要超出“证明漏洞存在所需的最小范围”去继续利用。那份政策写给安全研究，而不是普通 Claude 用户，但它仍然能说明 Anthropic 在“暴露内部系统材料如何处理”这件事上的公开态度。 基于这些来源可以做一个**明确标注为推断**的结论：Anthropic 的公开文档不支持“只要你看了泄露内容就会自动被封”这种广泛流传的说法。Opus 4.6 上某次网络安全请求被拦截，也不自动等于账号已经被封。但如果你的行为不是“我看了新闻”，而更接近“我保留、利用、扩散了暴露材料”，你就显然更接近 Anthropic 公开 policies 和 terms 真正在意的那类行为边界。 这个中间答案，比两种极端都更有用。`完全不会有事` 过于武断。`看一眼就封号` 也没有公开文档支撑。当前公开证据支持的，是一个更窄、更实用的说法：封号逻辑仍然是 policy-based，而不是简单的“接触即处罚”；warnings 和 appeals 是公开存在的；Anthropic 没有公开写出一个“阅读即封”的规则。 对普通用户来说，操作层面的结论其实很朴素： - 风险判断优先以 Anthropic 公开 help-center 和 policy 页面为准 - 不要把暴露出来的内部资产当成“官方允许使用的 surface” - 如果真的被误封，直接走公开 appeal path，而不是自行猜测封禁原因 ## Claude Code 当前公开模型到底是什么 泄露讨论还顺手带回了很多过时的模型认知。这个问题很重要，因为很多人会拿 leak 截图里的名字，去替代当前真正支持的 Claude Code 模型列表。 Anthropic 当前的 [Claude Code model configuration](https://support.claude.com/en/articles/11940350-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](https://support.claude.com/en/articles/12138966-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 里出现的新名字也不能替代公开支持模型列表。 ![Claude Code 当前模型时间线与弃用节点](https://blog.laozhang.ai/posts/zh/claude-code-source-leak-ban-policy/img/model-timeline.jpg) 这里还有两个对实际决策很重要的细节。 第一个是访问边界。Anthropic 的 model configuration 页面明确写着：在 Pro 方案下使用 Claude Code，如果你想用 Opus，需要先开启并购买 extra usage。这个事实对普通读者比任何 roadmap 猜测都更重要，因为它直接决定你现在是不是“理论上知道有 Opus 4.6”，还是“合同上真的能稳定用 Opus 4.6”。如果你想进一步看 plan 差异，可以读我们的 [Claude Code Pro vs Max 指南](https://blog.laozhang.ai/zh/posts/claude-code-pro-vs-max)。 第二个是长上下文。Anthropic 的 [Claude Code FAQ](https://support.claude.com/en/articles/12386420-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?](https://support.claude.com/en/articles/8987223-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](https://support.claude.com/en/articles/11145838-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](https://support.claude.com/en/articles/12304248-managing-api-key-environment-variables-in-claude-code) 页面里写得非常直白：Claude Code 会优先使用环境变量中的 API key，而不是你已登录的订阅身份。也就是说，如果 shell 里存在 `ANTHROPIC_API_KEY`，Claude Code 就会按这个 key 所属 API 账号计费，即使你同时已经用 Claude 订阅登录了 Claude Code。 ![Claude 订阅、Console 账号与 API Key 优先级关系图](https://blog.laozhang.ai/posts/zh/claude-code-source-leak-ban-policy/img/account-split.jpg) 可以把这套逻辑理解成三条平行路径： | 路径 | 它是什么 | 在 Claude Code 里的计费方式 | 常见误判 | | --- | --- | --- | --- | | Claude 订阅登录 | Free / Pro / Max / Team / Enterprise | 使用 plan 自带额度以及对应 extra usage 逻辑 | 误以为这也会自动覆盖 API key 情况 | | Console 账号 | API 组织与 pay-as-you-go 计费 | 使用 API credits、组织设置与 API 账单 | 误以为同邮箱就等于同预算池 | | `ANTHROPIC_API_KEY` 环境变量 | 明确的 API 身份覆盖 | 优先于订阅登录用于计费 | 忘了环境变量还在，以为自己仍在消耗 plan usage | 还有两个常见但很有实际价值的补充点。 第一，Anthropic 在 Pro/Max 那篇文章里明确写到：如果你当前是用 Claude Console PAYG 登录到 Claude Code，可以通过 `/login` 切回订阅计划。这不是小技巧，而是 Anthropic 官方提供的“在两套系统之间切换”的正确方式。 第二，Anthropic 的 [Claude Code FAQ](https://support.claude.com/en/articles/12386420-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 指南](https://blog.laozhang.ai/zh/posts/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 当前支持模型列表为准，而不是任何未进入公开文档的泄露命名。 如果你真正担心的是封号风险，那就把注意力拉回 Anthropic 的公开规则。当前公开文档支持的是一个基于 policy 和 terms 的 enforcement 视角，而不是一个“看一眼就封”的简单视角。如果你认为账号被误封，Anthropic 公开提供了 appeals 路径，这才是可执行的官方流程。 如果你是团队管理员或技术负责人，这次事件最值得你吸收的，不是“Anthropic 内部还有哪些隐藏功能”，而是你自己的团队很可能已经对登录路径、模型可用性和计费优先级存在长期误解。先把这些基础合同讲清楚，再谈更复杂的路线。 如果你是安全研究者或高阶用户，那么最该守住的是分类边界：了解暴露事实、按 Anthropic 公开产品合同正常使用服务、以及把暴露内部资产当成“可自由操作 surface”，这是三件完全不同的事。第一件很正常，第二件是必须的，第三件才是最容易把自己带进麻烦区的地方。 这件事最有价值的结论，其实也最不戏剧化：泄露是真的，但当前 Claude Code 的公开合同依然相当收敛。Anthropic 的帮助中心已经把当前支持模型、账号分流、计费优先级和公开封号边界写得足够清楚。先按这些真实合同做判断，决策边界会清楚得多。