1. 为什么有些环境必须离线安装

很多公司的研发电脑是不允许随便连外网的。可能是安全规定，也可能是网络隔离，代码和资料都不让出内网。

这时候如果你直接敲：

npm install -g @anthropic-ai/claude-code

大概率会卡住或者失败。原因很简单：这个命令要去外网下载东西，而你的电脑根本连不出去。

所以我们要解决的问题就是：在没有外网的情况下，怎么把 Claude Code 装好，并且还能正常登录、正常更新。

打个比方：正常安装就像去网上商店买软件；离线安装就像商店不送货，你得自己想办法把货弄进来。

2. Claude Code 安装时到底下载了什么

先搞清楚正常安装时发生了什么，后面才容易理解为什么要大费周章。

Claude Code 的安装并不是“下载一个文件就完事”，它大致会做这几件事：

• 从 npm 仓库下载 @anthropic-ai/claude-code 这个主包；
• 顺带下载它依赖的一大堆其他 npm 包；
• 可能还会下载一些二进制辅助组件（不是纯 JS 文件）；
• 第一次启动时，还要联网完成登录认证、初始化配置、检查版本等操作。

所以，离线安装不只是“拷一个安装包”，而是要把这一整套东西都提前准备好，凑齐了才行。

3. 离线安装，总共就三条路

其实思路并不复杂，常见的办法就三种：

方案	通俗理解	适合谁
方案一：npm 私有镜像	在公司内网自己开一个“内部软件商店”	想尽量少改动、团队有基础运维
方案二：离线打包直投	用 U 盘或内网共享，把软件拷过去装	网络完全隔离、机器不多
方案三：企业制品库统一分发	公司统一管理软件仓库，统一推送安装	规模较大、希望长期规范管理

简单说：

• 小打小闹，用方案二；
• 想省事复用，用方案一；
• 想一劳永逸，上方案三。

下面逐个说清楚。

4. 方案一：在公司内网搭一个 npm 私有镜像

这个方案的本质是：在外网正常的地方搭一个“中转仓库”，把需要的包都下载好，然后让内网机器从这个仓库安装。

常用工具有 Verdaccio 或 Nexus Repository。你可以把它理解成一个只对你公司内部开放的 npm “小卖部”。

大概流程是：

1. 在能连外网的机器上搭建 Verdaccio / Nexus；
2. 让它在第一次安装时把 @anthropic-ai/claude-code 以及所有依赖缓存下来；
3. 内网机器配置 .npmrc，把仓库地址指向这个内部源；

示例 .npmrc 写法：

registry=http://内网IP:4873
strict-ssl=false

4. 在内网机器上正常执行安装命令，但它会走内部源，不再需要访问外网。

这个方案的优点是：开发人员使用习惯基本不变，安装命令还是那一条。

缺点是：第一次“备货”要完整，依赖链路不能缺，否则安装依然会失败。

5. 方案二：离线打包，像用 U 盘拷贝游戏

如果内网完全隔离，连搭内部源的条件都没有，那就走最原始也最直接的方式：把要用的东西提前打包好，拷进去。

需要准备的材料大致有：

• Node.js 运行时压缩包（注意版本和架构要匹配）；
• Claude Code 主包及依赖缓存；
• 相关二进制组件。

操作步骤：

1. 在一台能联网的机器上安装并验证成功；
2. 把 Node.js、安装目录、npm 缓存等打包；
3. 通过 U 盘或者内网文件服务器传到目标机器；
4. 解压到指定目录，配置好 PATH 环境变量；
5. 运行 claude -v 之类的命令验证是否可用。

这个方案的好处是：完全不依赖 npm 仓库，网络彻底隔离也能用。

缺点也很明显：版本管理和更新都偏手工，机器一多就很累。

适合机器数量不多、网络管控非常严格的场景。

6. 方案三：让公司统一管理“软件仓库”

如果团队规模大，最好一开始就按规范来，用企业制品库统一分发。

比如用 Artifactory 或 Nexus，把 npm 包和二进制制品都放进公司统一的仓库里，再配合运维平台推送标准化安装脚本。

它的好处是：

• 版本可以统一锁定，所有人装的是同一个版本；
• 权限可以控制，谁能用谁不能用一目了然；
• 安装过程可以脚本化，新人也能一键完成；
• 后续更新、回滚都方便管理。

缺点是前期需要搭建和运维这套平台，对基建有一定要求。

一句话总结：短期看方案二省事，长期看方案三最省心。

7. 装好了，离线环境怎么登录

很多人以为离线安装就是“装完就能用”，其实登录这一步也很关键。

常见的认证方式有两种：

• API Key 登录：提前在联网环境生成好 Key，拿到内网机器上配置；
• 订阅账号授权：部分场景可以先用账号授权一次，把登录状态保存下来。

认证信息通常会写入本地配置文件或用户目录中。因此可以在联网的机器上先完成一次登录，再把相关配置和凭据一起带到离线机器上。

需要注意的是：并非所有认证流程都能完全离线完成，有些环节可能需要一次联网或人工配合，实际使用前最好先在公司网络里验证清楚。

另外，在涉密网络里保存认证凭据要特别小心，注意权限控制和加密存放。

8. 以后怎么更新和升级

装好只是第一步，长期使用一定会遇到“出新版本了要不要升”的问题。

通常建议这样处理：

• 固定一个稳定版本，不要跟着官方频繁升级；
• 需要升级时，先在联网机器上准备好新版本的离线物料；
• 再通过内部仓库或打包方式分发给内网机器；
• 升级前做好备份，出问题可以快速回滚。

公司内部最好有一个简单的版本发布节奏：什么时候升级、升级到哪个版本、变更了什么，都记录下来，方便追溯。

9. 常见问题排查

即使按照上面的步骤做，也可能遇到各种问题。这里列几个高频的：

• 安装成功后启动报错：优先检查 Node.js 版本、架构不匹配、环境变量配置是否生效；
• 一直卡住不动：看看是不是残留了代理设置，导致程序还在尝试访问外网；
• 提示找不到某个依赖或组件：说明离线物料没打包全，需要重新补货；
• 登录失败、提示权限不足：检查 API Key 是否正确、配置文件路径和权限是否正常；
• 网络超时：确认目标机器是否真的走的内网源，而不是偷偷访问外网地址。

排查原则很简单：先看环境变量，再看网络走向，最后查依赖是否完整。

10. 总结

Claude Code 的离线安装，核心就三句话：

1. 把需要的东西提前从外网“搬”进来；
2. 让内网机器从内部仓库或打包文件安装；
3. 登录信息和更新流程也要一起规划好。

对于大多数企业来说，最推荐的落地路线是：

• 先用 npm 私有镜像解决安装来源问题；
• 再配合企业制品库做版本锁定和统一分发；
• 最后形成标准化的安装脚本和更新流程。

这样既满足安全合规要求，又能让开发人员体面、省心地在内网使用 Claude Code。