Roo MCP fails to launch npx-based services on Windows due to an unparsed ${APPDATA} variable.

[oooojsw]

Title: Critical Bug: Roo MCP fails to launch npx-based services on Windows due to an unparsed ${APPDATA} variable.

Bug Description:

Hello, the Roo Code plugin is unable to start any MCP service that relies on npx on the Windows operating system. It consistently fails with the following error log, regardless of any system or user configuration:

code
Code
npm ERR! code ENOENT
npm ERR! syscall lstat
npm ERR! path C:\Users[YourUsername]\${APPDATA}
npm ERR! errno -4058
npm ERR! enoent ENOENT: no such file or directory, lstat 'C:\Users[YourUsername]\${APPDATA}'
Analysis:

The core issue is that the plugin injects a literal, unparsed ${APPDATA} string into the execution environment's path when calling npx. This is the Linux/macOS variable syntax and it is not resolved on Windows, causing npm to fail.

Troubleshooting Steps Attempted (All Failed):
We have exhaustively tried to fix this from the user side, but the bug overrides all configurations:

Setting npm_config_cache globally via .npmrc.

Setting npm_config_cache via VS Code's terminal.integrated.env.windows in settings.json.

Setting npm_config_cache as a system-level environment variable.

Using a .bat script wrapper to launch npx. Even when the script successfully changes the working directory to %USERPROFILE%, the ${APPDATA} string is still appended to the path, proving it is being injected by the plugin's execution logic itself.

Conclusion:

This is a critical bug within the plugin's process spawning logic on Windows that makes a significant portion of MCP services unusable. Please investigate how external commands are being called and ensure that environment variables are correctly resolved for the target operating system.

[aniruddhaadak80]

This sounds like a legitimate cross-platform environment expansion bug, especially since you already tested multiple user-side overrides and the literal ${APPDATA} path is still leaking into execution. Once the wrong token is injected downstream of user config, there is not much left for users to fix locally.nnIf the maintainers can reproduce it, the real fix is probably in how the process environment or spawn command is assembled on Windows, not in npm configuration guidance.