Skip to main content
Features Cart

Guides

Which VS Code Versions Does Power Claude Support? A Compatibility Guide

Neural-LLM Admin 6 min read
Power Claude editor compatibility matrix showing supported VS Code versions

You ran the one-line installer, it said it was done, and yet the version in your editor is not the one the website lists as current. Or the install failed outright with a terse "not compatible with VS Code" and no hint about what to do next. Both are the same underlying issue: a VS Code extension declares a minimum editor version it needs to run, and when your editor is older than that floor, the install is refused — sometimes loudly, sometimes by quietly leaving you on the last build that still fit. This guide explains exactly which versions Power Claude supports, why the floor exists, how to check your own setup in ten seconds, and — the part most compatibility pages skip — how every claim in our support matrix is backed by a real, reproducible install rather than a hand-typed checkmark.

The short answer

Power Claude is a VS Code extension, so its compatibility is governed by the same engines contract every extension uses: a minimum VS Code version, and a Node.js version for the parts that run outside the editor (the pc command-line tool and the local rotation proxy). The current build targets a recent VS Code engine and Node 20+. The authoritative, always-current numbers live on the compatibility page — this post explains how to read them and what they mean for you.

Two things are worth separating up front, because conflating them is the source of most confusion:

  1. The editor requirement is hard. If your VS Code (or Cursor / VSCodium / Windsurf) is older than the declared floor, the extension will not install. This is enforced by your editor, not by us — the editor reads the extension's engines.vscode field and refuses anything it cannot guarantee.
  2. The Node requirement is soft. The extension itself runs inside the editor's own runtime and does not need a system Node. Node only powers the pc CLI and the local proxy. Miss it, and those features degrade — the extension still installs and runs.

That hard-vs-soft split is deliberate, and it is exactly how our installer treats your machine.

Why an install silently sticks on an old build

This is the failure mode that sends people to the changelog wondering why their version is "wrong."

When a new Power Claude release raises its minimum editor version, an editor below that floor cannot accept the new build. If you installed through the marketplace's auto-update, the update simply does not apply — you stay on the last release your editor could run, with no error, because from the editor's perspective nothing failed. You are not on a broken version; you are on the newest version that your editor is allowed to run.

We have seen this exact case on our own machines: an editor one minor version below the floor sat on a months-old build while every other editor on the same box ran the current release. Nothing was broken. The editor was just too old for the new engine, and the auto-updater correctly declined rather than installing something it could not vouch for.

The fix is always the same: update your editor, then reinstall. The trick is knowing that is the fix, which is why our installer now tells you so directly instead of letting you discover it three weeks later.

Check your setup in ten seconds

You do not need to read a table to know where you stand. From a terminal:

code --version

The first line is your editor version. Compare it to the floor on the compatibility page. If you are at or above it, you can run the current build. If you are below it, update your editor first.

For the command-line companion:

node --version

Node 20 or newer unlocks the pc CLI and the local proxy. Below that — or no Node at all — the extension still works; you just will not have the terminal tooling until you install it.

The installer checks this for you — before it fails

Our one-line installer (curl -fsSL https://neural-llm.com/media/downloads/install.sh | bash) is not a blind download-and-install. Before it touches your editor it runs a small dependency doctor that reads the requirements out of the package you just downloaded — not a number hard-coded in the script that could drift from the real build — and checks them against your machine:

  • Editor too old? It stops with a plain-language message naming your version, the version required, and how to update — instead of handing your editor a package it will reject with a cryptic error.
  • Node missing or old? It tells you the pc CLI and proxy need it, prints both a no-sudo install path (per-user via nvm) and a system path, and continues anyway — installing the extension so its core features work now, and nudging you to add Node when convenient.
  • Everything present? It verifies the download's published SHA-256, installs into your editor's extension directory only, and uses no sudo and makes no system changes.

The point is that a missing dependency should never be a dead end. Either the installer resolves what it safely can without root, or it hands you the exact command to run. A dependency that gates only one feature degrades only that feature — it never blocks the whole install.

How we prove the matrix — every claim is a real run

Here is the part that matters for trust, and the reason this is more than a table of checkmarks.

A compatibility matrix is easy to fake. Anyone can type "supported" into a cell. The question a careful reader should ask is: how do you know? Our answer is that each entry in the matrix is backed by an actual install attempt, not an assertion.

Behind the scenes, a sandbox harness takes the exact .vsix we ship and installs it into a series of pinned, throwaway editor containers — each one a specific, real VS Code version. For every version it records what actually happened:

  • The install succeeded and the extension registered → that version is proven compatible.
  • The editor refused the package because its engine was below the floor → that version is proven incompatible, and the matrix states plainly rather than pretending.

That evidence — the version tested, the result, and when it was checked — is what feeds the support tier you see. When we say a version is supported, it is because the current build was just installed into that version and came up clean. When we mark one end-of-life, it is because that editor genuinely rejected the build. No guesswork, and nothing that can quietly drift away from reality between releases.

We hold the same line on the version numbers themselves. The build number in the extension, the file you download, the "current" entry in our release records, and the changelog all derive from one source — so the version you install is the version the site claims is current. We even added a guard that refuses to publish a download whose internal build number does not match its filename, precisely so a mislabeled artifact can never make the site advertise a version that does not really exist.

What to do right now

  1. Run code --version and compare it to the compatibility page.
  2. If you are below the floor, update your editor, then run the installer again.
  3. If you want the pc CLI and proxy, make sure Node 20+ is on your PATH.
  4. Install from the download page — the installer will catch anything above before it becomes a confusing error.

Compatibility should be boring: you check one number, you are either above the line or you update, and the thing installs. The work we put into the doctor, the matrix, and the substantiation harness all exists to keep it that way — and to make sure that when we tell you a version works, we have actually watched it work.