Claude Code CLI 运行后跳到 Bun 帮助页面?一次定位 PATH、npm 与安装异常的排查记录
问题现象:明明执行的是 claude,为什么出来的是 Bun 的帮助信息?
如果你在 PowerShell 中执行:
claude
结果看到的不是 Claude Code 界面,而是下面这类输出:
Bun is a fast JavaScript runtime, package manager, bundler, and test runner.
Usage: bun <command>
...
那么首先可以确定一件事:
这并不是 Claude Code 正常启动后的输出。
从现象来看,系统最终执行到了 Bun,而不是预期中的 Claude Code 入口程序。
很多人在看到这一长串帮助信息时,会误以为是 Claude Code 报错。实际上,这更像是一种“走错路”的情况:你以为启动的是 Claude Code,但命令链路中的某个环节把请求转给了 Bun。
本文记录一次完整的排查过程,以及如何利用 PowerShell 快速确认问题出在哪里。
先看异常输出到底说明了什么?
看到 Bun 的帮助页面时,最重要的信息不是页面内容,而是页面为什么会出现。
输出内容大致如下:
Bun is a fast JavaScript runtime...
Commands:
run
test
install
add
remove
build
create
upgrade
...
这种输出通常表示:
bun
被直接执行了。
而不是:
claude
成功启动后打印的内容。
换句话说,系统最终调用到了 Bun 可执行文件,但没有收到正确参数,因此 Bun 按照默认行为展示了帮助页面。
这意味着问题大概率出在以下几个方向:
| 排查方向 | 说明 |
|---|---|
| PATH 冲突 | claude 实际指向了错误位置 |
| npm 全局安装异常 | 启动脚本损坏 |
| Claude CLI 被覆盖 | 同名命令被其他包占用 |
| Bun 关联错误 | 启动脚本意外调用 Bun |
真正的问题并不在 Bun 本身,而在命令解析过程。
如何确认系统实际执行的是哪个 claude?
最直接的方法是使用 PowerShell 查看命令来源。
执行:
Get-Command claude
实际得到的结果如下:
CommandType Name Version Source
----------- ---- ------- ------
ExternalScript claude.ps1 C:\Users\陈思言\AppData\Roaming\npm\...
看到这里,已经获得了一个非常关键的信息。
系统找到的并不是:
claude.exe
而是:
claude.ps1
并且位置在:
C:\Users\陈思言\AppData\Roaming\npm\
这说明当前机器上的 Claude 命令来自:
npm 全局安装目录。
也就是说,PowerShell 在执行:
claude
时,本质上执行的是:
claude.ps1
然后再由这个脚本去调用后续程序。
问题很可能就出在这里。
为什么 claude.ps1 值得重点怀疑?
很多命令行工具在 Windows 上安装后都会生成三个入口:
xxx
xxx.cmd
xxx.ps1
例如:
claude
claude.cmd
claude.ps1
PowerShell 优先执行 .ps1 文件。
因此整个调用链实际上变成了:
PowerShell
↓
claude.ps1
↓
Node 或 Bun
↓
Claude Code
如果其中任意一个环节配置错误,就可能出现完全不同的结果。
例如:
PowerShell
↓
claude.ps1
↓
Bun
↓
Bun Help
这就解释了为什么用户执行的是 Claude,却看到了 Bun。
第一步:确认到底安装了什么包
当发现命令来自 npm 目录时,下一步不是重装,而是先确认安装内容。
执行:
npm list -g --depth=0
或者:
npm ls -g --depth=0
重点观察列表中是否存在:
@anthropic-ai/claude-code
以及是否存在其他名称相近的包。
实际排查时,经常会出现两种情况。
情况一:官方包存在
例如:
@anthropic-ai/claude-code
已经安装。
这时候更可能是:
-
安装损坏 -
启动脚本损坏 -
依赖异常
情况二:安装的并不是官方包
有些环境中可能存在其他名称类似的包。
这种情况下:
claude
调用的可能根本不是 Claude Code。
现象上看起来一样,但原因完全不同。
第二步:查看 claude.ps1 到底在执行什么
很多问题不需要猜。
直接打开脚本即可。
执行:
Get-Content "$env:APPDATA\npm\claude.ps1"
重点观察以下内容:
node xxx.js
还是:
bun xxx.js
或者其他命令。
如果脚本内部最终调用了:
bun
那么问题基本已经锁定。
因为这与实际现象完全一致。
为什么会出现 Bun 被意外调用的情况?
从这次排查过程来看,有一个比较明显的特征。
用户执行:
claude
之后看到的是:
Bun is a fast JavaScript runtime...
而不是:
Claude Code ...
说明某个环节最终运行成了:
bun
而非:
node
或者 Claude Code 的真实入口。
这类问题通常表现为:
-
命令存在 -
不提示找不到命令 -
但执行结果完全不对
因此很多人第一反应会怀疑 Claude 本身。
实际上更应该检查命令解析路径。
第三步:确认系统中是否存在多个 claude
Windows 环境下还存在一种常见问题:
多个同名命令同时存在。
执行:
where.exe claude
可能看到类似结果:
C:\Users\xxx\AppData\Roaming\npm\claude
C:\Users\xxx\AppData\Roaming\npm\claude.cmd
C:\Users\xxx\AppData\Roaming\npm\claude.ps1
如果未来又安装了其他版本,还可能出现更多路径。
此时需要确认:
系统究竟优先执行哪一个。
因为 PATH 顺序不同,最终结果也会不同。
很多命令冲突问题,本质上就是 PATH 优先级问题。
重新安装是否有必要?
如果确认:
@anthropic-ai/claude-code
已经存在,但仍然出现 Bun 页面,那么重新安装是合理的下一步。
卸载:
npm uninstall -g @anthropic-ai/claude-code
安装:
npm install -g @anthropic-ai/claude-code
安装完成后验证:
claude --version
如果能够正常输出版本号,说明命令入口已经恢复正常。
如果依旧出现 Bun 页面,则问题仍然停留在命令解析阶段,需要继续检查脚本内容和 PATH 配置。
一个容易忽略的判断技巧
很多人排查 CLI 工具时,会先研究报错内容。
这次情况恰恰相反。
真正重要的不是 Bun 帮助页面写了什么,而是:
为什么 Bun 会出现在这里。
Claude Code 正常启动时,本不应该进入 Bun 的帮助逻辑。
因此看到:
Bun is a fast JavaScript runtime...
这条信息本身就已经是一条线索。
它告诉我们:
当前系统执行链路中的某个节点,已经偏离了 Claude Code 的正常启动路径。
后面的排查工作,其实都围绕这个事实展开。
排查流程汇总
如果你遇到同样的问题,可以按照下面顺序检查。
1. 查看命令来源
Get-Command claude
确认来自哪里。
2. 查看全部路径
where.exe claude
确认是否存在多个同名命令。
3. 查看安装包
npm list -g --depth=0
确认是否安装:
@anthropic-ai/claude-code
4. 查看启动脚本
Get-Content "$env:APPDATA\npm\claude.ps1"
确认脚本最终执行了什么。
5. 验证版本
claude --version
观察是否仍然跳转到 Bun。
6. 必要时重装
npm uninstall -g @anthropic-ai/claude-code
npm install -g @anthropic-ai/claude-code
重新生成入口文件。
实用摘要
本次问题的核心并不是 Claude Code 本身,而是命令执行路径异常。
出现 Bun 帮助页面时,可以先记住三个判断:
-
看到 Bun 帮助页面,不代表 Bun 出错。 -
更大的可能是 Claude 命令没有正确进入 Claude Code。 -
先检查命令来源,再考虑重装。
实际排查中最有价值的命令是:
Get-Command claude
仅这一条命令,就能确认系统当前到底在执行什么。
一页速览
| 项目 | 结果 |
|---|---|
| 执行命令 | claude |
| 实际输出 | Bun Help 页面 |
| 已确认信息 | 命令来自 claude.ps1 |
| 所在目录 | AppData\Roaming\npm |
| 当前判断 | npm 全局安装入口参与执行 |
| 优先检查 | Get-Command claude |
| 下一步检查 | npm list -g --depth=0 |
| 深入排查 | 查看 claude.ps1 内容 |
| 修复手段 | 重装 Claude Code 包 |
FAQ
执行 claude 出现 Bun 页面一定是 Bun 的问题吗?
不是。更常见的是 Claude 命令链路出现异常,最终误进入 Bun。
Get-Command claude 有什么作用?
用于确认 PowerShell 实际执行的是哪个文件。
为什么看到的是 claude.ps1?
因为 PowerShell 优先执行脚本入口。
npm 安装目录出现 claude.ps1 正常吗?
正常。许多全局安装的 CLI 都会生成对应脚本。
什么时候需要查看 claude.ps1?
当命令行为与预期明显不一致时。
重装 Claude Code 能解决所有问题吗?
不能。如果 PATH 或脚本本身存在冲突,重装后仍可能复现。
where.exe claude 的作用是什么?
用于查看系统中存在多少个同名命令。
最先执行哪条排查命令?
建议先执行:
Get-Command claude
它能最快告诉你问题大概在哪一层。

