这篇文章记录了一次比较真实的安装过程:我们不是在一台"干净、完整、什么工具都有"的 Linux 上安装 Claude Code,而是在一个条件比较受限的 WSL 环境里,让 Codex 直接接管终端,把 Claude Code 的安装、配置、验证和清理全部做完。
📌 适用场景
如果你的环境也有下面这些特征,这篇记录会非常有参考价值:
- 你在使用 WSL
- 你想让 AI 代理(Agent)直接代操作,而不是自己手敲全部命令
- 机器上没有现成的 Node.js / npm
- 连
curl、wget这种基础下载工具都不一定有- 你希望 Claude Code 走 API key + 中转站,而不是通过浏览器 OAuth 登录

🎯 本次目标
这次要达成的目标非常明确,拒绝稀里糊涂的"一键安装":
- 在当前的受限 WSL 环境里成功安装 Claude Code。
- 配置好全局的
claude环境变量与命令入口。 - 通过 API key 顺利接入自定义的中转站。
- 验证命令和模型调用真的能跑通。
- 清理安装过程中留下的失败下载和调试残留文件。
🔍 1. 先判断环境,不要上来就装
Codex 接管终端后的第一件事不是"直接安装",而是先摸清底层环境。实际的检查结果是:
- 系统:
Ubuntu Core 24on WSL2 node:不存在npm:不存在curl:不存在wget:不存在- 机器上已经有一部分 Claude 相关目录,但状态极其不完整。
💡 避坑点:
这一步很关键。因为 Claude Code 最常见的安装方式是 npm install -g @anthropic-ai/claude-code。但在一个连 Node 都没有的环境里,硬走 npm 路线只会无谓地浪费时间解决依赖问题。
⚠️ 2. 发现已有残留,先判断是不是"坏安装"
Codex 接着检查了系统中已有的 Claude 目录,发现了以下线索:
~/.claude/~/.claude.json~/.claude/downloads/claude-2.1.74-linux-x64~/.local/share/claude/versions/2.1.74
表面上看起来像是"装过了",但继续深挖就发现了不对劲:
- 下载下来的二进制文件大小只有约 47 MB。
- 官方 manifest 里对应的 Linux x64 包大小应该是约 235 MB。
- 版本目录下只有一个 0 字节的占位文件。
结论很直接: 这不是"已安装",而是一次失败或网络中断后留下的"半安装状态"。
🛠️ 3. 安装策略调整:为什么改用"手动拉取官方二进制"?
官方给的另一条路线是原生安装脚本,大意类似:
bash
curl -fsSL [https://claude.ai/install.sh](https://claude.ai/install.sh) | bash
问题在于当前环境没有 curl,而且脚本本身也高度依赖 curl 或 wget。所以 Codex 做了一个更稳的替代方案:
- 先从官方发布地址读取
latest版本。 - 再读取对应版本的
manifest.json。 - 拿到 Linux x64 二进制的官方 SHA256 哈希值。
- 用 Python 脚本直接下载二进制。
- 本地校验 SHA256。
- 校验通过后再落位安装。
这套做法有两个核心好处:
- 完全不依赖系统里有没有
curl/wget。 - 能先确认本地拿到的包是不是完整、可信的,避免损坏的二进制文件带来灵异 Bug。
📥 4. 下载官方版本并做校验
Codex 实际做的事不是盲目下载,而是先查发布元数据。下载逻辑可以概括为:
text
1. 读取 latest,得到当前版本号(如 2.1.74)
2. 读取 manifest.json,找到 linux-x64 的 checksum
3. 下载官方 claude 二进制
4. 对下载结果做 sha256 校验
这次拿到的有效版本是 2.1.74。在校验通过之后,才继续下一步。这里遇到一个中间坑:
- 单线程下载太慢。
- 第一次并发 Range 下载虽然下满了大小,但合并出来的文件哈希不对。
- 解决方案: 后面改成"分片分别落文件,再顺序合并",问题迎刃而解。
这也是这次安装里很典型的一点:Codex 不是只会"照着教程跑死命令",而是会根据现场失败情况灵活更换工程方案。
🔗 5. 手动安装 Claude Code 命令入口
由于官方内置的安装器在这个环境里表现并不稳定,最后采用的是 "手动落位 + 手动建入口" 的方式。
最终保留的二进制路径是:
text
~/.local/share/claude/native/claude-2.1.74
命令入口则是一个符号链接:
text
~/.local/bin/claude
对应的 Shell 侧处理是确保 ~/.local/bin 在 PATH 环境变量里。Codex 在 ~/.bashrc 里补了这段逻辑:
bash
if [ -d "$HOME/.local/bin" ] && [[ ":$PATH:" != *":$HOME/.local/bin:"* ]]; then
PATH="$HOME/.local/bin:$PATH"
fi
这样新开一个 Shell 之后,直接输入 claude -v 就能拿到版本号了。
🔑 6. 改用 API key,而不是浏览器登录
一开始 Claude Code 默认拉起的是浏览器 OAuth 登录流程,但考虑到环境受限,后面决定改用 API key + 中转站。
这时 Codex 没有把 key 硬塞到临时环境变量里,而是规范地写进了 Claude Code 的用户级配置文件:
文件路径: ~/.claude/settings.json
配置结构大致如下:
json
{
"$schema": "[https://json.schemastore.org/claude-code-settings.json](https://json.schemastore.org/claude-code-settings.json)",
"env": {
"ANTHROPIC_AUTH_TOKEN": "sk-xxxx",
"ANTHROPIC_BASE_URL": "[https://your-gateway.example.com](https://your-gateway.example.com)",
"CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC": "1"
}
}
参数解析:
ANTHROPIC_AUTH_TOKEN:用来存放 API key。ANTHROPIC_BASE_URL:用来指向你的中转站或 API 网关。CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC=1:可以减少一些非必要的遥测或背景请求。
🐛 7. 真实踩坑:默认模型能连通,但不可用
配置完之后,并不是"立刻就好了"。Codex 用最小请求做联调:
bash
claude -p "Reply with exactly OK and nothing else."
结果返回的不是鉴权失败,也不是路径错误,而是中转站返回了类似这样的错误:
"当前模型 claude-sonnet-4-6 负载已经达到上限,请稍后重试"
这说明本地配置其实已经通了 ,问题出在网关后面的默认模型不可用。于是 Codex 做了第二轮探测:临时把默认模型切到 claude-opus-4-6 再测。结果请求立即成功返回:OK。
所以最终把模型指定也一并写进了配置:
json
{
"$schema": "[https://json.schemastore.org/claude-code-settings.json](https://json.schemastore.org/claude-code-settings.json)",
"env": {
"ANTHROPIC_AUTH_TOKEN": "sk-xxxx",
"ANTHROPIC_BASE_URL": "[https://your-gateway.example.com](https://your-gateway.example.com)",
"ANTHROPIC_MODEL": "claude-opus-4-6",
"ANTHROPIC_DEFAULT_HAIKU_MODEL": "claude-opus-4-6",
"ANTHROPIC_DEFAULT_OPUS_MODEL": "claude-opus-4-6",
"ANTHROPIC_DEFAULT_SONNET_MODEL": "claude-opus-4-6",
"CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC": "1"
}
}
⚠️ 注意: 这不是"最佳通用模板",而是针对这条中转线路的实测可用配置。如果你的网关后面
sonnet正常,就没必要全部照抄成opus,毕竟opus通常更贵。
✅ 8. 最后怎么验证它真的可用?
这次最终做了三层严谨的验证,缺一不可:
1. 验证命令是否存在
bash
claude -v
# 预期输出: 2.1.74 (Claude Code)
2. 验证认证状态
bash
claude auth status
得到的关键信息是:
json
{
"loggedIn": true
}
3. 验证真正的模型调用(端到端测试)
bash
claude -p "Reply with exactly OK and nothing else."
# 预期输出: OK
只有到了这一步,才算安装和配置真正完成!
🧹 9. 安装完成后,Codex 又做了什么清理?
这一步很多网上的教程都不会写,但在工程实践中实际非常有必要。因为这次过程里产生过不少残留:
- 失败下载下来的损坏二进制包
/tmp里的临时安装脚本- 分片下载留下的临时目录
- 大量的调试日志
- 失败安装生成的 0 字节占位版本文件
- 测试时生成的本地会话记录和备份目录
最后 Codex 进行了清理,只保留了真正需要的内容:
~/.local/bin/claude~/.local/share/claude/native/claude-2.1.74~/.claude/settings.json- Claude Code 运行时还会继续使用的正常目录
这一步做完之后,你的 WSL 环境会干净很多,不会留下历史包袱。
💡 10. 这次过程里最值得总结的几点
- 先探环境,再选安装路线: 没有
node/npm,就不要死磕 npm,转换思路海阔天空。 - "像装过"不代表"真的能用": 看到
~/.claude和下载目录,不代表安装已经完成。文件大小、校验和、入口是否存在都要一一核实。 - 中转站问题和本地配置问题要分开看: 如果报的是模型拥塞,不一定是你本地的网络或鉴权配错了。
- 端到端验证必须包含真实请求: 只看
claude -v没意义,真正有价值的是claude -p "..."能不能成功返回结果。 - 事后顺手清理残留: 失败下载、临时日志、测试记录如果不清,后面排障时目录结构会越来越乱。
🛡️ 我会给自己的一个安全建议
如果你准备把 API key 发给 AI 代理代为配置,最好把它当成一次性暴露过的凭据来处理:
- 配置确认无误后,去中转站或上游后台旋转(Rotate)并作废旧 key。
- 生成新 key,并手动更新进
~/.claude/settings.json。 - 绝对不要在博客、截图、聊天记录里保留真实的密钥片段。
📝 参考命令速查
| 功能 | 命令 |
|---|---|
| 查看版本 | claude -v |
| 查看认证状态 | claude auth status |
| 最小请求测试 | claude -p "Reply with exactly OK and nothing else." |
| 重新加载环境变量 | source ~/.bashrc |
结语
这次最有意思的地方,并不是"Claude Code 到底该怎么安装",而是观察 Codex 在一个不那么理想的环境里,是如何一步一步把问题拆开解构的:
从判断环境缺什么 ➡️ 识别坏安装 ➡️ 更改安装路线 ➡️ 校验二进制 ➡️ 手动建入口 ➡️ 配 API key 和网关 ➡️ 真实请求验证 ➡️ 最后清理残留。
如果你愿意让 AI 代理真正接管终端,这种**"先诊断、再实施、再验证、再清理"**的闭环工作流,通常比单纯照抄干瘪的安装文档要稳健得多。