This morning, when I opened PowerShell as usual and typed claude, I got this error:

claude: The term 'claude' is not recognized as a name of a cmdlet,
function, script file, or executable program.

It was working fine just yesterday.

In these situations, engineers tend to think "I didn't change anything..." but honestly, something has changed. The question is whether I changed it, the tool changed, or the environment changed.

At first I thought "Maybe Windows Update ran," but intuitively felt "that doesn't seem right."

Isolating the Problem: Try Reinstalling First

Reading the error message, the claude command is said to "not exist." In other words, Windows can't find this command anywhere.

I tried running the official installation command:

irm https://claude.ai/install.ps1 | iex

The installation itself succeeded, but at the end I got this warning:

✅ Installation complete!

‼ Setup notes:
  • Native installation exists but C:\Users\[username]\.local\bin
    is not in your PATH. Add it by opening: System Properties →
    Environment Variables → Edit User PATH → New → Add the path above.
    Then restart your terminal.

"PATH is not configured"

This caught my attention because I didn't get this message when I installed it before.

What is PATH (This is Actually Key)

Just to clarify, PATH is "a list of locations where Windows searches for commands".

For example, when you just type claude, Windows searches in this order:

  1. Is there a claude.exe in the current directory?
  2. Is there a claude.exe in folders registered in PATH?

Even if the executable file exists in a folder not registered in PATH, Windows will return "I don't know that command."

In other words, claude.exe exists, but Windows can't find it.

Temporary Fix: Get It Working First

I wanted to resume work, so I first set the environment variable in PowerShell:

[Environment]::SetEnvironmentVariable(
  "Path",
  $env:Path + ";C:\Users\[username]\.local\bin",
  "User"
)

After restarting PowerShell, the claude command worked successfully.

But I didn't want to end there.

Why did it work until yesterday, but today I need to configure PATH?

Finding the Root Cause: Reading Official Documentation

Honestly, I got stuck here for a bit. Searching didn't immediately find articles about people encountering the same problem.

So I carefully reread the official documentation and found this sentence:

"Some users may be automatically migrated to an improved installation method."

That's it, I thought.

In other words, some users are automatically migrated to an improved installation method.

The puzzle pieces fell into place.

Yesterday's State

Today's State

In other words, the installation method itself changed due to Claude Code's automatic update.

Why From npm to Native Installation?

A question arose here: Why was migration necessary?

npm-based installation actually has several problems:

  1. Dependency on Node.js

    • Node.js is required just to use Claude Code
    • Need to manage Node.js versions
    • Possible involvement in npm's own troubles

  2. Global Package Conflicts

    • Risk of conflicts with other tools
    • npm's global environment becomes bloated

  3. Update Complexity

    • npm cache issues
    • Resolving package dependencies

On the other hand, native installation:

Technically, native installation makes more sense.

But the migration timing was without notice, so I panicked a bit in the morning. It felt like the usual road was suddenly closed.

If You Encounter the Same Problem

If you encounter the same problem, you can solve it with the following steps:

1. If You Want to Use It Immediately (Temporary)

Run with full path:

C:\Users\[username]\.local\bin\claude.exe

Or set PATH for the current session only:

$env:Path += ";C:\Users\[username]\.local\bin"
claude

2. If You Want a Permanent Solution (Recommended)

Set environment variable in PowerShell:

[Environment]::SetEnvironmentVariable(
  "Path",
  $env:Path + ";C:\Users\[username]\.local\bin",
  "User"
)

Be sure to restart PowerShell after execution.

If you want to set it via GUI:

  1. Win + R → Type sysdm.cpl and press Enter
  2. "Advanced" tab → "Environment Variables" button
  3. In "User variables," select "Path" → "Edit"
  4. Click "New" button
  5. Add C:\Users\[username]\.local\bin
  6. Close all with "OK"
  7. Restart PowerShell

Balance Between Tool Evolution and User Experience

What I reconsidered from this incident is that tool evolution isn't always smooth.

From the developer's side, they want to migrate to a better architecture. Reduce dependencies and improve maintainability. That's the right decision.

But from the user's side, "something that worked until yesterday suddenly doesn't work" is quite stressful when starting work in the morning.

Honestly, I don't even know if there was advance notice of the migration.

It might have been written in the release notes, or an email might have come. But if you ask whether I meticulously watch the release notes of tools I use daily, I don't.

Am I at fault? You might say yes. But I also think that's realistic tool usage.

If you have 10, 20 tools you use daily, tracking all their release notes isn't realistic. Watching GitHub Releases, checking Discord announcement channels, regularly reading official blogs... doing all that would prevent actual work from progressing.

Ultimately, I think tool users must take the stance of "investigate when something goes wrong."

This might be unsatisfying from the development side. Even carefully written release notes aren't read. Migration guides are only referenced after problems occur.

But I think that's the relationship between tools and users, which I realized again from this experience.

Preparing for Next Time

That said, from this experience, I decided to review some habits:

  1. Read error messages carefully

    • This time too, the solution was written in the warning message
    • Don't rush and skip over it

  2. When thinking "it worked until yesterday," check official documentation first

    • Look at official sources before searching
    • Be especially careful with tools that have automatic updates

  3. Periodically review environment variable settings

    • Make a habit of checking what PATH contains
    • Check for unnecessary paths remaining

I was going to write "regularly check release notes," but honestly I'm not confident I can make that a habit. I only listed what I can realistically continue.

If you encounter the same problem, I hope this article helps.

Related Books

For those who want to understand Claude Code more deeply, the following books are recommended.

[📦 商品リンク: moshimo-book-fINTJ]

[📦 商品リンク: moshimo-book-9CeFY]