Claude Code CLI Opens the Bun Help Screen Instead of Starting? A Practical Troubleshooting Guide for PATH, npm, and Installation Issues
Running claude Shows Bun Instead of Claude Code
If you type:
claude
and instead of launching Claude Code you see something like this:
Bun is a fast JavaScript runtime, package manager, bundler, and test runner.
Usage: bun <command>
...
you are not looking at a Claude Code error.
What actually happened is that your command execution chain ended up invoking Bun, not Claude Code.
This situation can be confusing because the command itself exists and executes successfully. There is no “command not found” error. Yet the wrong application starts.
After investigating this issue on a Windows system, I found that the root cause usually lies somewhere between PowerShell, npm global packages, PATH resolution, and startup scripts.
This article walks through the entire troubleshooting process.
What Does the Bun Help Screen Actually Tell Us?
The most important clue is not the text displayed on the screen.
The important question is:
Why did Bun appear at all?
The output typically looks like:
Bun is a fast JavaScript runtime...
Commands:
run
test
install
add
remove
build
...
This is Bun’s default help screen.
It appears when Bun itself is executed without the expected parameters.
In other words, somewhere along the startup process, the system effectively ran:
bun
instead of successfully launching Claude Code.
That immediately narrows the investigation to a few possibilities:
| Possible Cause | Description |
|---|---|
| PATH conflict | The claude command points to the wrong executable |
| Broken npm installation | Startup scripts are corrupted |
| Command name collision | Another package registered the same command |
| Bun integration issue | The startup script unexpectedly calls Bun |
At this stage, Bun is not necessarily the problem. It is simply the final application that received the command.
First Check: What Is PowerShell Actually Executing?
The quickest way to understand what’s happening is:
Get-Command claude
In the investigated case, the result was:
CommandType Name Version Source
----------- ---- ------- ------
ExternalScript claude.ps1 C:\Users\...\AppData\Roaming\npm\...
This immediately revealed something important.
PowerShell was not launching:
claude.exe
Instead, it was executing:
claude.ps1
located inside the npm global installation directory.
That means the command flow looked something like this:
PowerShell
↓
claude.ps1
↓
Node.js or Bun
↓
Claude Code
If any link in that chain is broken, the final result can be completely different from what you expect.
In this case, the chain appeared to become:
PowerShell
↓
claude.ps1
↓
Bun
↓
Bun Help Screen
That explains the behavior perfectly.
Why the claude.ps1 Script Matters
On Windows, many CLI tools installed through npm generate multiple launcher files:
claude
claude.cmd
claude.ps1
PowerShell generally prefers the PowerShell script version.
So when you type:
claude
you are often executing:
claude.ps1
rather than the actual application binary.
This script acts as a bridge between PowerShell and the underlying runtime.
If the script is misconfigured or references the wrong runtime, unexpected behavior follows.
Step 1: Verify Which Package Is Installed
Before reinstalling anything, determine exactly what npm installed.
Run:
npm list -g --depth=0
Look for:
@anthropic-ai/claude-code
The results usually fall into two categories.
Scenario A: The Official Package Is Installed
If you see:
@anthropic-ai/claude-code
then the issue is more likely related to:
-
Corrupted installation -
Damaged launcher scripts -
Dependency conflicts
Scenario B: Another Package Owns the Command
If a different package registered the claude command, PowerShell may be launching an entirely different application.
The symptoms can look identical, even though the root cause is completely different.
Step 2: Inspect the Startup Script
Instead of guessing, inspect the script directly.
Run:
Get-Content "$env:APPDATA\npm\claude.ps1"
Pay attention to what the script eventually executes.
For example:
node some-file.js
or
bun some-file.js
If the script explicitly invokes Bun, you’ve likely found the source of the issue.
The observed behavior matches exactly what would happen if the launcher unexpectedly redirected execution into Bun.
Why Bun Sometimes Appears Unexpectedly
One detail stood out during troubleshooting.
The user executed:
claude
and received:
Bun is a fast JavaScript runtime...
instead of any Claude Code output.
That strongly suggests the startup process ultimately reached:
bun
rather than:
node
or Claude Code’s intended entry point.
This is why the error can feel misleading.
Nothing explicitly says “Claude Code failed.”
The command succeeds.
The wrong application simply starts.
Step 3: Check for Multiple Claude Commands
Windows systems often accumulate multiple command registrations over time.
Run:
where.exe claude
You might see:
C:\Users\...\AppData\Roaming\npm\claude
C:\Users\...\AppData\Roaming\npm\claude.cmd
C:\Users\...\AppData\Roaming\npm\claude.ps1
In some environments, additional entries may appear.
At that point, the next question becomes:
Which one does PowerShell prioritize?
PATH order determines which executable wins.
Many CLI issues ultimately turn out to be simple command-resolution conflicts.
Should You Reinstall Claude Code?
If the official package is already installed but execution still lands inside Bun, reinstalling is a reasonable next step.
Remove the package:
npm uninstall -g @anthropic-ai/claude-code
Install it again:
npm install -g @anthropic-ai/claude-code
After installation, verify the result:
claude --version
If a version number appears, the launcher has likely been restored successfully.
If Bun still appears, the issue remains somewhere in the command-resolution layer rather than the package itself.
The Key Insight That Saved Time
Many troubleshooting sessions start by analyzing the error message.
In this case, that approach leads in the wrong direction.
The critical observation is not what Bun says.
The critical observation is that Bun appears at all.
Claude Code should not normally end up inside Bun’s help system.
The moment you recognize that, the investigation becomes much more straightforward.
Instead of debugging Claude Code, you start tracing command execution.
That shift in perspective usually saves a lot of time.
Recommended Troubleshooting Workflow
If you encounter the same problem, follow this sequence.
1. Identify the Command Source
Get-Command claude
2. List All Matching Commands
where.exe claude
3. Verify Installed Packages
npm list -g --depth=0
Check whether:
@anthropic-ai/claude-code
is present.
4. Inspect the Launcher Script
Get-Content "$env:APPDATA\npm\claude.ps1"
5. Test Version Output
claude --version
6. Reinstall If Necessary
npm uninstall -g @anthropic-ai/claude-code
npm install -g @anthropic-ai/claude-code
Quick Summary
If running claude opens the Bun help screen:
-
Do not assume Bun is broken. -
The command likely never reached Claude Code. -
Investigate command resolution before reinstalling everything.
The single most useful diagnostic command is:
Get-Command claude
It immediately reveals what PowerShell is actually executing and often points directly to the root cause.
One-Page Reference
| Item | Result |
|---|---|
| Command Executed | claude |
| Unexpected Output | Bun help screen |
| Confirmed Launcher | claude.ps1 |
| Location | AppData\Roaming\npm |
| Most Likely Area | npm global command registration |
| First Diagnostic Step | Get-Command claude |
| Package Verification | npm list -g --depth=0 |
| Deep Inspection | Check claude.ps1 |
| Potential Fix | Reinstall Claude Code |
FAQ
Does the Bun help screen mean Bun is broken?
No. It usually means the command execution path unexpectedly ended inside Bun.
Why is Get-Command claude important?
It shows exactly what PowerShell launches when you type claude.
Why do I see claude.ps1 instead of claude.exe?
PowerShell commonly prioritizes PowerShell launcher scripts.
Is it normal for npm to create claude.ps1?
Yes. Many globally installed CLI tools generate PowerShell launcher scripts.
When should I inspect claude.ps1?
Whenever the command behaves differently from what you expect.
Can reinstalling Claude Code always fix the issue?
No. PATH conflicts and launcher script problems can survive a reinstall.
What does where.exe claude tell me?
It lists every matching command available on the system.
Which command should I run first?
Start with:
Get-Command claude
It provides the fastest insight into where the problem is occurring.
