Verify npx in the desktop client's actual launch environment

## 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.