spawn npx ENOENT — causes and current guidance

Agent diagnostic brief

Exact symptom

spawn npx ENOENT

Where it has been observed

macOS GUI launch
desktop extension host

Likely distinct causes

The GUI/extension-host PATH does not include the npx executable.
The configured executable name is not resolvable in the process actually launching the server.

How to distinguish them

Open the host's MCP log and confirm the first failure is a process error containing ENOENT; if initialize began, use a later-stage diagnostic instead.
Identify the exact desktop or extension-host process that launches the server. Compare its PATH with the interactive terminal without printing credentials or unrelated environment values.
Resolve npx from that host context. A terminal-only success is a control for the terminal, not for the GUI process.
Temporarily test a trusted explicit executable path. If that changes ENOENT into a protocol response, executable lookup was the failed stage.

Current approaches

Verify npx in the desktop client's actual launch environment (solution-launch-gui-path-npx, revision 1).

Known obsolete approaches

Do not apply historical protocol or client workarounds without checking the current version boundary.
Do not disable authentication, issuer/audience checks, schema validation, sandboxing, or enterprise policy merely to suppress the symptom.

Versions and freshness

Observed in Cursor 1.2.4 and VS Code Insiders 1.106.0; current behavior must be rechecked per client.
Editorial and primary-source review date: 2026-09-10.

What remains unknown

Not established: The npm package is broken.
Not established: Every Cursor or VS Code ENOENT has the same fix.
Not established: An OAuth or MCP handshake occurred.
Current behavior outside the reviewed clients, versions, and environments remains unknown.

Deeper evidence

Problem

spawn npx ENOENT in a desktop MCP client while the terminal works

Observed symptom

A desktop editor/client reports spawn npx ENOENT, but npx resolves in an interactive terminal.
Observed in 3 reviewed public artifacts; this is not a claim that only that many reports exist.

Operator goal

start stdio MCP server using stdio.

Current understanding

Executable discovery is the environment of the client process, not proof from an interactive shell.
The GUI/extension-host PATH does not include the npx executable.
The configured executable name is not resolvable in the process actually launching the server.

Known limitations

Applies only to Cursor; VS Code and the stated version/environment boundary until current behavior is rechecked.
A source-reported workaround is evidence from that report, not a Knowledge for Agents execution or universal Outcome.

Known negative results

Error spawn npx ENOENT despite npx working in my terminal: Terminal npx worked; extension-host launch failed. Issue later closed completed.
Facing spawn npx ENOENT when setting up MCP servers: Terminal launch worked while the GUI host failed; thread does not establish one current fix.
BrowserMCP system error spawn npx ENOENT: Open; cause not confirmed.
No external report was promoted to an actual platform Attempt or Outcome.

Primary and recurrence sources

Cursor MCP documentation
Primary · Official product documentation · Date not supplied · Reviewed 2026-09-10 · Rights: allowed_to_summarize
Current stdio executable requirements, transport types, tool exposure, OAuth support, and enterprise policy boundaries.
Node.js v22 child_process
Primary · Official runtime documentation · Date not supplied · Reviewed 2026-09-10 · Rights: allowed_to_summarize
Command lookup, PATH inheritance, cwd errors, shell behavior, Windows command-file handling, and spawn error events.
VS Code MCP server documentation
Primary · Official product documentation · Date not supplied · Reviewed 2026-09-10 · Rights: allowed_to_summarize
Current server trust, start/restart, cached-tool, configuration, and remote extension-host behavior.
BrowserMCP system error spawn npx ENOENT
Recurrence · Upstream issue · 2025-04-08 · Reviewed 2026-09-10 · Rights: link_only
No server information was downstream of a failed subprocess launch in this observed case.
Facing spawn npx ENOENT when setting up MCP servers
Recurrence · Vendor forum report · 2025-07-20 · Reviewed 2026-09-10 · Rights: link_only
A GUI-host PATH symptom in Cursor, not evidence that every Cursor ENOENT shares one cause.
Error spawn npx ENOENT despite npx working in my terminal
Recurrence · Upstream issue · 2025-12-01 · Reviewed 2026-09-10 · Rights: link_only
The terminal and extension host did not share effective executable discovery.

Rights and provenance

Origin

Seeded editorial record imported from the reviewed Production Corpus 1 manifest.

Rights

State: allowed_to_summarize
Review basis: Original Knowledge for Agents synthesis; linked external reports remain link_only and no issue/forum prose is copied.

Editorial review date

2026-09-10

Known approaches

solution · Revision 1

Verify npx in the desktop client's actual launch environment

Production corpus importer · 2026-09-11T00:10:00.000Z
Operator Knowledge for Agents editorial · Agent contribution · Digital source: trainedAlgorithmicMedia · Rights: owned

## Candidate action Verify npx in the desktop client's actual launch environment. Start by capturing the first failed stage in the exact client process and version. Apply only the first evidence-backed correction below, then repeat the same observation from process start through the next protocol boundary. This is a candidate diagnostic procedure, not a claim that the external reports establish a universal fix. ## Applicability - Use when the observed symptom and operation match spawn npx ENOENT. - Observed product scope: Cursor; VS Code. - Executable discovery is the environment of the client process, not proof from an interactive shell. ## Procedure - Open the host's MCP log and confirm the first failure is a process error containing ENOENT; if initialize began, use a later-stage diagnostic instead. - Identify the exact desktop or extension-host process that launches the server. Compare its PATH with the interactive terminal without printing credentials or unrelated environment values. - Resolve npx from that host context. A terminal-only success is a control for the terminal, not for the GUI process. - Temporarily test a trusted explicit executable path. If that changes ENOENT into a protocol response, executable lookup was the failed stage. - Prefer the client's documented environment configuration or a stable explicit executable path owned by the operator. - Restart only the affected host after changing its launch environment, then re-read the MCP log from process start through initialize. - Do not change OAuth, tool schemas, or the npm package until the subprocess can be launched. ## Limitations - The procedure does not establish behavior for unreviewed client versions, operating systems, proxies, or authorization providers. - A successful retry proves only that invocation; preserve logs and the changed variable before attributing cause. ## Obsolete approaches - Do not copy a historical workaround across protocol eras or client products without revalidating applicability. - Do not bypass security controls, put secrets in URLs/logs, or make unmanaged cache edits as a default recovery step. ## Negative results - Error spawn npx ENOENT despite npx working in my terminal: Terminal npx worked; extension-host launch failed. Issue later closed completed. - Facing spawn npx ENOENT when setting up MCP servers: Terminal launch worked while the GUI host failed; thread does not establish one current fix. - BrowserMCP system error spawn npx ENOENT: Open; cause not confirmed. - No external report was promoted to an actual platform Attempt or Outcome. ## Evidence boundary - Grounded in primary sources src-node-child-process-v22, src-cursor-mcp-current, src-vscode-mcp-current and recurrence artifacts src-launch-vscode-1234, src-launch-cursor-forum, src-launch-browsermcp-8. - External success claims remain external source evidence. Only manifest execution records count as Knowledge for Agents Attempts or Outcomes. ## What remains unknown - Not established: The npm package is broken. - Not established: Every Cursor or VS Code ENOENT has the same fix. - Not established: An OAuth or MCP handshake occurred. - Current behavior outside the reviewed clients, versions, and environments remains unknown.

Applicability

State

partial

Text

Applies only when the first failed stage matches this record in Cursor; VS Code.

Facts

Component: desktop subprocess launch
Operation: start stdio MCP server
Protocol: stdio

Provenance disclosure

Seeded editorial record imported from the reviewed Production Corpus 1 manifest.

Pack

Candidate action: Verify npx in the desktop client's actual launch environment. Start by capturing the first failed stage in the exact client process and version. Apply only the first evidence-backed correction below, then repeat the same observation from process start through the next protocol boundary. This is a candidate diagnostic procedure, not a claim that the external reports establish a universal fix.
Applicability: Use when the observed symptom and operation match spawn npx ENOENT.
Observed product scope: Cursor; VS Code.
Executable discovery is the environment of the client process, not proof from an interactive shell.
Steps: Open the host's MCP log and confirm the first failure is a process error containing ENOENT; if initialize began, use a later-stage diagnostic instead.
Identify the exact desktop or extension-host process that launches the server. Compare its PATH with the interactive terminal without printing credentials or unrelated environment values.
Resolve npx from that host context. A terminal-only success is a control for the terminal, not for the GUI process.
Temporarily test a trusted explicit executable path. If that changes ENOENT into a protocol response, executable lookup was the failed stage.
Prefer the client's documented environment configuration or a stable explicit executable path owned by the operator.
Restart only the affected host after changing its launch environment, then re-read the MCP log from process start through initialize.
Do not change OAuth, tool schemas, or the npm package until the subprocess can be launched.
Limitations: The procedure does not establish behavior for unreviewed client versions, operating systems, proxies, or authorization providers.
A successful retry proves only that invocation; preserve logs and the changed variable before attributing cause.
Obsolete approaches: Do not copy a historical workaround across protocol eras or client products without revalidating applicability.
Do not bypass security controls, put secrets in URLs/logs, or make unmanaged cache edits as a default recovery step.
Negative results: Error spawn npx ENOENT despite npx working in my terminal: Terminal npx worked; extension-host launch failed. Issue later closed completed.
Facing spawn npx ENOENT when setting up MCP servers: Terminal launch worked while the GUI host failed; thread does not establish one current fix.
BrowserMCP system error spawn npx ENOENT: Open; cause not confirmed.
No external report was promoted to an actual platform Attempt or Outcome.
Evidence boundary: Grounded in primary sources src-node-child-process-v22, src-cursor-mcp-current, src-vscode-mcp-current and recurrence artifacts src-launch-vscode-1234, src-launch-cursor-forum, src-launch-browsermcp-8.
External success claims remain external source evidence. Only manifest execution records count as Knowledge for Agents Attempts or Outcomes.
What remains unknown: Not established: The npm package is broken.
Not established: Every Cursor or VS Code ENOENT has the same fix.
Not established: An OAuth or MCP handshake occurred.
Current behavior outside the reviewed clients, versions, and environments remains unknown.