安装 AI 编程工具，别只认包名

熟悉的产品名称不等于发布者身份

这个包的名字里写着 Claude。可是，谁将获得在您机器上运行代码的权限？安全地安装 AI 编程工具，首先要在授予它访问代码仓库或凭据的权限之前，确认这层关系。一个 npm 包名、一段令人信服的描述和一个耳熟能详的产品词，都不能证明它得到了该产品厂商的授权。

2026 年 10 月 19 日，GitHub 针对下列 8 个以 AI 为主题的 npm 包名发布了恶意软件公告。这些公告是调查某次安装的理由，但并不能证明官方的 Claude、Codex 或 ChatGPT 产品遭到了入侵。本指南基于公告记录和官方文档，并未声称对恶意软件做过拆解分析或运行过样本。[1][2][3]

Flagged package names; do not install

claude-desktop-setup       @decoopus/claude-setup
codex-setup                chatgpt-desktop-setup
@decoopus/chatgpt-setup     chatgpt-pro-activator
chatgpt-pro-setup-tool     api-anthropic

下架并不能告诉我们载荷做了什么

所查阅的公告认定了这些恶意软件，但没有提供这一组样本的行为分析。截至 10 月 20 日，本文所参考的资料都无法确定读取了哪些文件、是否针对某个特定的凭据存储，或安装了何种持久化机制。给它安上某个窃密木马家族的名字，只是用故事而不是证据来填补空白。这些包主题相同，但仅凭这一点并不能证明它们出自同一个攻击者。[1][2][3]

下载量也解决不了这个问题。下载可能是自动化的、重复的，或是出于分析目的进行的；它既不等于确认执行，也不等于有人受到了影响。对于正在评估自身风险的团队来说，更有力的证据是安装记录中确切的包名和版本、安装位置，以及代码是否在能接触到重要资产的情况下运行过。请把执行状态记录为“未知”，而不要把缺少遥测数据当作安全的证据。

从厂商出发，再沿着分发渠道追踪

对于 Claude Code，Anthropic 在文档中注明的官方 npm 身份是 @anthropic-ai/claude-code，同时也提供原生安装渠道。名字相似的安装包并不会继承这层关系。这个方法适用于任何编程工具：从厂商文档中的安装页面出发，按照对应平台的确切渠道安装，而不是从搜索结果里随手挑一个包。[4]

企业流程应当让经过验证的选择易于重复。维护一份简短的已批准工具清单，记录文档 URL、分发渠道、预期的发布者、选定的版本以及负责更新的人。锁定包版本能让所选的字节或版本可以重复获取，但并不能证明最初的选择是正当的。还要审查更新路径，因为明天的安装可能根本不需要有人再复制一遍命令。

Proposed approved-tool record

Vendor documentation URL -> exact distribution identity
Version + platform        -> expected artifact
Publisher / signing key   -> trust anchor
Artifact hash             -> recorded bytes
Update mechanism          -> owner and review policy
Runtime permissions       -> separately approved access

校验和需要一个可信的比对来源

校验和证明的是字节与预期摘要一致。如果字节和摘要都来自同一个不可信的分发者，这种一致并不能说明是谁生成了它们。Anthropic 的文档说明，从 Claude Code 2.1.89 开始提供带签名的发布清单，更早的清单只有校验和而没有独立签名。请先用文档中公布的签名密钥指纹验证清单，再把所选平台的二进制文件与经过认证的清单进行比对。[4]

在 Windows 上，文档中的原生二进制文件还带有 Authenticode 签名。下面的检查命令不会运行该程序。既要检查签名是否有效，也要确认发布者身份是预期的 Anthropic, PBC；随便一个有效的签名者是不够的。这些是文档中给出的验证步骤，并不表示本文下载或验证过某个二进制文件。[4]

# Inspect an already-downloaded binary; do not execute it
Get-AuthenticodeSignature -LiteralPath .\claude.exe |
  Select-Object Status, SignerCertificate
Get-FileHash -LiteralPath .\claude.exe -Algorithm SHA256

# Compare signer and hash with the vendor's documented trust chain.

来源已验证，仍需要做权限决策

签名和来源检查回答的是“从哪里来”的问题，并不能证明代码中没有恶意行为或漏洞。npm 在介绍来源证明时明确说明了这一点：它把包与源代码和构建信息关联起来以便审查，而不是证明它无害。请把检查结果当作关于该制品的一项证据，而不是把机器上所有凭据都交给它的理由。[5]

我接下来要问的是：安装后的程序能接触到什么。对于已批准的编程工具，要审查其进程能访问的仓库内容、环境变量、凭据存储和网络。把开发环境的访问与生产环境凭据分开，任何额外权限都应经过审慎决定。这项建议针对的是一般意义上的执行权限，并不是断言被下架的包使用了某种特定的窃取手法。

跳过安装脚本，CLI 就安全了吗？

npm 的 ignore-scripts 选项会在安装时屏蔽 package.json 中的脚本，但文档明确说明，像 npm run 这样被显式调用的脚本仍会执行其命令。它并不是为您随后启动的程序准备的沙箱。一个团队屏蔽了生命周期脚本，随后又运行了未经验证的 CLI，实际上是做出了另一个执行决策。请单独评估这个决策。[6]

这里还存在实际的兼容性代价：一些合法的包确实需要执行安装步骤。正确的做法是设立明确的、经过审查并注明理由的例外，而不是因为某个工具安装失败就全局关闭这项控制。在审批记录中，要把元数据检查、安装和执行区分开来。每一步提供的证据不同，可能暴露的能力也不同；任何一步都不应悄悄替代下一步。

如果您安装过被标记的包，请先保全证据

恶意软件公告建议，把安装过该包的机器视为已被攻陷，并在另一台电脑上轮换已暴露的密钥。请与您的事件响应团队一起执行这些建议：隔离受影响的环境，保全安装记录和进程记录，并确认它能接触到哪些凭据。仅仅删除这个包，并不能证明由此产生的访问或持久化已经消失。[1][2]

这与断言某个具体载荷的行为是刻意区分开的。您可以认真对待控制工作，同时对未知的部分保持准确。在案件记录中保存包的标识和版本，以及执行证据和已审查的凭据。不要把仍然有效的密钥值粘贴到工单里，也不要用不可信的工作站来生成替换的密钥。

把安装变成一项工程决策

我会要求团队为每个已批准的工具展示一条完整的链条：厂商指向这个渠道，制品与这个经过认证的版本一致，进程获得的是这些有文档记录的访问权限。另一位工程师可以复核这条链条。一张熟悉的 Logo 截图或一个包的下载计数器，都无法取代它。

这属于安全软件工程的工作，因为这些选择会成为新人入职、CI 和自动更新流程的一部分。如果每个开发者都要独自重新做一遍信任判断，组织实际上就把一项本可重复执行的安全控制交给了搜索结果。把经过验证的路径建好一次，明确它的负责人，并把它的执行权限收窄到足以自证合理的程度。