简介：这份离线安装包面向需要在公司内网、局域网大模型环境下使用 Claude Code 的开发者与运维人员，解决外网不可达时工具链无法安装、插件无法下载的问题。资源共 32 个文件，以 exe、whl、zip、md、json、cjs 等类型为主，涵盖 Git、Node、Python、VS Code 等运行时安装程序，Claude Code 主程序与 VS Code 插件 vsix，以及 vivado-mcp、python-pptx 等离线库文件，压缩包约 615.57MB，采用 7z 格式打包。内容按环境依赖分层组织，安装脚本与说明文档齐备，便于在断网条件下一次性完成部署。已有 519 人学习关注，适合需要在内网搭建本地 AI 编码辅助环境的团队参考，可快速获得可复用的离线组件清单、插件与库文件，减少逐项联网查找与版本适配的试错成本。
1. 离线环境里跑 Claude Code：为什么“装不上”比“不会用”更让人头疼
很多团队在隔离网络或内网开发机上第一次接触 Claude Code 时，卡住的地方往往不是模型能力，而是最基础的一步——装不上。终端里敲下安装命令，进度条转两圈就报网络超时；换台机器把全局目录拷过去，运行又提示依赖缺失。这类问题在需要离线安装包的场景里特别集中：开发机不出网、CI 构建节点只允许白名单、或者你只是想在本地留一份可复现的安装介质，避免每次重装都重新拉一遍。
Claude Code 本质是一个跑在终端里的命令行工具，通过 Node.js 生态分发，运行时依赖一组 npm 包和本地配置目录。所谓“离线安装包”，核心就是把在线安装过程中会去远端拉取的那些东西，提前在一台能联网的机器上固化下来，再整体搬到目标机器。它解决的不是功能问题，而是分发和复现问题：让同一套版本在任意机器上装出同样的结果，不依赖当时的网络状况。
这篇文章面向三类人：需要在隔离环境部署终端 AI 编码工具的工程师、要给团队做统一开发环境镜像的维护者、以及想搞清楚 Claude Code 安装链路到底依赖了什么的开发者。下面从依赖拆解讲到打包、搬运、验证，把每一步的命令和参数都落到能直接抄的程度。
2. 拆开 Claude Code 的安装链路：到底哪些东西需要离线
2.1 在线安装时，终端背后发生了什么
在能联网的机器上执行官方推荐的安装方式，通常会走 npm 全局安装或官方安装脚本两条路。以 npm 路径为例，命令大致是这样：
# 在线机器上执行，用于观察安装链路 npm install -g @anthropic-ai/claude-code --verbose加上--verbose是为了看清它到底访问了哪些地址、下载了哪些 tarball。你会看到 npm 先解析依赖树，然后从 registry 拉取主包和若干传递依赖，最后写入全局node_modules并在 bin 目录生成可执行入口。安装脚本路径则更直接，它会下载一个预编译产物或引导脚本，再调用 npm 完成剩余步骤。
关键认知是：Claude Code 不是一个静态二进制，它的运行依赖 Node.js 运行时和一批 npm 包。离线安装要固化的，正是“Node 运行时 + 全局包目录 + 配置目录”这三块。少任何一块，搬到目标机器上都可能起不来。
2.2 三类必须固化的产物
把安装链路拆细，需要离线搬运的产物可以归为三类，下面这张表是我在实际操作中总结的清单：
| 产物类型 | 具体内容 | 是否必须 | 说明 |
|---|---|---|---|
| Node 运行时 | Node.js 二进制或压缩包 | 必须 | 目标机器没有合适版本时需一并搬运 |
| 全局包目录 | node_modules下的包文件 | 必须 | 核心可执行逻辑都在这里 |
| 配置与缓存 | 用户主目录下的配置文件夹 | 建议 | 含登录态、偏好设置，缺失需重新配置 |
| 安装脚本 | 引导脚本或 tarball | 可选 | 用于在目标机器重建安装流程 |
Node 运行时的版本要和打包机器保持一致，大版本不一致时原生模块可能加载失败。全局包目录是最容易漏的部分，很多人只拷了可执行文件，结果运行时找不到依赖。配置目录决定了搬过去之后要不要重新登录和设置，属于体验层面的东西，但省掉它能少很多重复劳动。
2.3 版本锁定：离线包可复现的前提
离线安装最大的价值是可复现，而可复现的前提是版本锁定。在线安装默认会拉最新版，今天打的包和下周打的包可能不是同一个版本。正确做法是在打包机器上先确定版本号，再围绕这个版本固化所有产物。
# 查看当前安装的版本，记录下来 npm list -g @anthropic-ai/claude-code # 如需指定版本安装，用 @ 加版本号 npm install -g @anthropic-ai/claude-code@<版本号>把版本号写进你的打包脚本注释里，目标机器安装后用同样的命令核对。版本对不上时，先怀疑打包时没锁版本，而不是怀疑搬运过程出了问题。这一步看起来简单，却是后面所有排查工作的基准线。
3. 在一台联网机器上打出可搬运的离线包
3.1 准备打包环境与目录结构
打包机器需要能正常访问 npm registry，Node.js 版本建议和目标机器保持一致。先建一个干净的打包工作目录，避免把机器上已有的全局包混进来。
# 建立打包工作区 mkdir -p ~/claude-offline/pack cd ~/claude-offline # 确认 Node 与 npm 版本，记录下来 node -v npm -v目录结构建议分成pack（存放打包产物）和stage（存放待搬运的完整目录树）两块。pack放压缩包，stage放解压后的内容，搬运时整体打包stage即可。这样做的原因是：压缩包在传输中可能损坏，保留一份解压后的目录便于比对。
3.2 用 npm pack 固化全局包
npm 提供了npm pack命令，可以把指定包及其依赖打成 tarball。对全局安装的包，更稳妥的方式是直接把全局node_modules目录整体复制出来，因为npm pack默认只打单个包，不包含完整依赖树。
# 查看全局 node_modules 路径 npm root -g # 将全局包目录复制到 stage 中 GLOBAL_ROOT=$(npm root -g) mkdir -p ~/claude-offline/stage/node_modules cp -r "$GLOBAL_ROOT"/@anthropic-ai ~/claude-offline/stage/node_modules/ 2>/dev/null # 复制 bin 目录下的可执行入口 mkdir -p ~/claude-offline/stage/bin cp "$(npm bin -g)"/claude ~/claude-offline/stage/bin/ 2>/dev/nullnpm root -g返回全局包安装位置，不同系统和 Node 版本下路径不同，所以用变量接住而不是写死。cp -r复制时带上@anthropic-ai这个 scope 目录，因为包名带 scope 时实际路径是嵌套的。bin 目录里的可执行文件通常是一个软链接或包装脚本，复制时要确认它指向的实际文件也在node_modules里。
3.3 打包 Node 运行时与配置目录
如果目标机器没有 Node.js，或者版本不匹配，需要把运行时也打进去。官方提供的压缩包解压即用，适合离线搬运。
# 下载对应平台的 Node 压缩包（在联网机器上执行） # 以 Linux x64 为例，版本号按需替换 curl -O https://nodejs.org/dist/v20.11.0/node-v20.11.0-linux-x64.tar.xz # 解压到 stage 目录 mkdir -p ~/claude-offline/stage/node tar -xf node-v20.11.0-linux-x64.tar.xz -C ~/claude-offline/stage/node --strip-components=1配置目录一般在用户主目录下，名称与工具相关。打包前先确认它的位置，再整体复制。注意配置里可能包含登录凭证，搬运到共享环境前要评估是否该带上，或者搬过去后重新登录。
# 复制配置目录（路径按实际工具约定调整） mkdir -p ~/claude-offline/stage/config cp -r ~/.claude ~/claude-offline/stage/config/ 2>/dev/null3.4 生成校验清单并压缩
打包完成后生成一份文件清单和校验值，搬运到目标机器后先核对再安装。这一步是离线流程里最容易被跳过、但出问题时最省事的环节。
# 生成文件清单与校验值 cd ~/claude-offline/stage find . -type f -exec sha256sum {} \; > ../manifest.sha256 # 整体压缩 cd ~/claude-offline tar -czf claude-offline-$(date +%Y%m%d).tar.gz stage manifest.sha256find配合sha256sum把每个文件的校验值写进清单，目标机器上用sha256sum -c就能批量核对。压缩包命名带上日期，方便区分不同批次。打包完成后先在本地解压一次，确认目录结构完整，再拿去搬运。
4. 把离线包搬到目标机器并完成安装
4.1 传输与解压后的目录校验
离线包传到目标机器后，第一步不是急着安装，而是校验完整性。传输过程丢文件、压缩包截断，都会在安装阶段才暴露，提前核对能省掉大量排查时间。
# 解压 tar -xzf claude-offline-20250101.tar.gz cd stage # 校验文件完整性 sha256sum -c ../manifest.sha256校验通过后再看目录结构，确认node_modules、bin、node、config四块都在。如果校验失败，先重新传输，不要试图跳过损坏的文件继续安装，那样只会在运行时出现更难定位的错误。
4.2 配置环境变量与可执行入口
目标机器上需要让系统找到 Node 运行时和可执行入口。最干净的做法是通过环境变量临时指定，验证通过后再写入 shell 配置文件。
# 临时指定 Node 与可执行路径 export PATH="$PWD/node/bin:$PWD/bin:$PATH" # 验证 Node 可用 node -v # 验证可执行入口能找到 which claudePATH的顺序很重要，把离线包里的 Node 放在前面，避免目标机器上已有的旧版本抢先被找到。which claude返回的路径应该指向离线包里的 bin 目录，如果指向了系统其他位置，说明 PATH 顺序不对。
4.3 首次运行与登录态处理
环境变量配好后，直接运行可执行入口，观察是否正常启动。首次运行通常会检查配置目录，如果打包时带了配置，可能直接进入可用状态；如果没带，会引导重新配置。
# 首次运行 claude --version # 如需指定配置目录位置 export CLAUDE_CONFIG_DIR="$PWD/config/.claude" claude--version是最轻量的验证方式，能打印版本说明可执行文件和依赖都加载正常。如果报模块找不到，多半是node_modules路径没对上，检查可执行入口里的引用路径是否指向了离线包内的目录。配置目录用环境变量指定，可以避免污染目标机器的用户主目录。
4.4 固化安装结果：写入 shell 配置
验证通过后，把环境变量写入 shell 配置文件，让每次登录都自动生效。写入前先备份原文件，这是基本习惯。
# 备份并追加配置 cp ~/.bashrc ~/.bashrc.bak cat >> ~/.bashrc <<'EOF' # Claude Code 离线安装 export CLAUDE_OFFLINE_ROOT="$HOME/claude-offline/stage" export PATH="$CLAUDE_OFFLINE_ROOT/node/bin:$CLAUDE_OFFLINE_ROOT/bin:$PATH" export CLAUDE_CONFIG_DIR="$CLAUDE_OFFLINE_ROOT/config/.claude" EOF # 重新加载 source ~/.bashrc用CLAUDE_OFFLINE_ROOT变量统一管理路径，后续迁移目录时只改这一处。写入后新开一个终端验证，确认claude --version仍然正常。这一步做完，离线安装才算真正落地，而不是停留在当前会话里。
5. 离线安装最容易翻车的几个地方
5.1 现象：运行时报模块找不到
原因通常是只复制了可执行文件，没有复制完整的node_modules依赖树，或者复制时漏掉了 scope 目录。可执行入口内部通过相对路径或require加载依赖，路径断了就报错。
解决方式是回到打包机器，用npm root -g确认全局包完整路径，重新整体复制。复制后对比两边的文件数量，差异过大说明漏拷。校验清单在这一步能直接指出缺了哪些文件。
5.2 现象：Node 版本不匹配导致原生模块加载失败
原因在于打包机器和目标机器的 Node 大版本不一致，某些包在安装时会编译原生模块，换版本后二进制不兼容。报错信息里通常带NODE_MODULE_VERSION字样。
解决办法是统一 Node 版本，把打包机器的运行时一并搬过去，并用 PATH 优先级确保目标机器用的是离线包里的 Node。不要试图在目标机器上重新编译，离线环境往往缺编译工具链，会引入新的依赖问题。
5.3 现象：配置目录权限或路径不对
原因是配置目录复制时保留了原机器的用户权限，或者环境变量指向的路径和实际解压路径不一致。表现是启动后反复要求登录，或者读不到已有配置。
解决方式是确认CLAUDE_CONFIG_DIR指向的目录存在且当前用户可读写，必要时用chmod调整权限。路径不一致时，用realpath打印实际路径再对照环境变量，别靠肉眼比对。
5.4 现象：搬运后校验值对不上
原因是传输过程不完整，或者打包时文件清单生成在压缩之后，导致清单本身没被包含进去。校验失败时不要抱侥幸心理继续安装。
解决办法是重新传输并重新校验，确认压缩包大小和源端一致。生成清单要在压缩之前，且清单文件本身也要放进压缩包，否则目标机器上没有比对基准。
5.5 现象：多台机器安装结果不一致
原因是打包时没有锁定版本，不同批次拉了不同的包。表现是同样的操作步骤，有的机器能用有的不能用。
解决办法是每次打包都记录版本号，把npm list -g的输出存进包内。目标机器安装后用同样命令核对，版本不一致就重新打包，不要在多台机器上分别“就地修复”，那样只会让环境越来越乱。
6. 让离线包长期可用的两个习惯
第一个习惯是给离线包做版本目录管理。不要把所有批次的包都解压到同一个目录，而是按版本号分目录存放，环境变量指向当前使用的版本。切换版本时只改环境变量，回滚也只是改回去。这样做的直接好处是：某次升级出问题时，你有后悔药可吃，不用重新走一遍打包流程。
# 按版本分目录 ~/claude-offline/ v1.0.0/ stage/ manifest.sha256 v1.1.0/ stage/ manifest.sha256 # 切换版本只改这一处 export CLAUDE_OFFLINE_ROOT="$HOME/claude-offline/v1.1.0/stage"第二个习惯是定期在干净环境里做一次“冷启动验证”。找一台没装过任何相关工具的机器，或者用一个干净的容器，从解压开始完整走一遍安装流程。这一步能暴露很多在“已经装过”的机器上被掩盖的问题，比如隐式依赖了系统里已有的某个库。我一般会在每次打包后做一次冷启动，确认从零到可用不超过十分钟，超过就说明包里有该固化但没固化的东西。
验证方法上，除了--version，还可以跑一个最小交互，确认工具能正常读取配置并响应输入。如果这一步卡住，优先检查配置目录和网络相关的设置，离线环境下任何试图访问外部的行为都会超时。把超时时间调短、把外部访问关掉，能让问题更快暴露。
最后说个我踩过的坑：早期打包时图省事，直接把打包机器的整个全局目录拷过去，结果目标机器上多了一堆无关的包，排查依赖冲突时非常痛苦。后来改成只复制必要的 scope 目录，包体积小了，问题也少了。离线包不是越全越好，而是越准越好。希望帮到你。
本文还有配套的精品资源，点击获取
