Qwen Code in Visual Studio Code cannot connect to Unity MCP but Claude Code can

[cowenchin]

What happened?

Cannot execute Unity MCP even others provider like Claude Code able to do so in Qwen Code Visual Studio Code extension

What did you expect to happen?

Use Unity MCP for tasks it able

Client information

Qwen Code: 0.21.0 (5610eb4)
Runtime: Node.js v24.18.0 / npm unknown
LSP: disabled
OS: win32 x64 (10.0.19045)
Auth: Token Plan
Base URL: https://token-plan.ap-southeast-1.maas.aliyuncs.com/compatible-mode/v1
Model: qwen3.8-max-preview
Fast Model: qwen3.8-max-preview
Session ID: 51d70d4e-413e-4238-9b6d-d77883d7f4b8
Sandbox: no sandbox
Proxy: no proxy
Memory Usage: 285.4 MB

Login information

No response

Anything else we need to know?

No response

[qwen-code-ci-bot]

✅ Qwen Triage finished — view run. See the stage comments above for the result.

✅ Qwen Triage 已完成 —— 查看运行。结果见上方各阶段评论。

[qwen-code-ci-bot]

Triage

• Type: bug
• Labels: type/bug, scope/mcp, scope/vscode, category/integration, status/need-information
• Next: need reproduction details from reporter

Thanks for reporting! This looks similar to #3033 (Unity MCP worked in CLI but not in the VS Code extension). To investigate, we need a few more details:

1. MCP configuration — how is Unity MCP configured? Please share the relevant mcpServers entry from your settings.json (or .qwen/settings.json / .mcp.json). Is it a stdio command or an HTTP/SSE URL?
2. Error output — what exactly happens when you try to use Unity MCP? Does the server fail to start, do tools not appear, or do tools appear but fail when called? Any error messages in the output or in the VS Code Output panel (Qwen Code channel)?
3. CLI vs extension — does Unity MCP work when you run qwen in a terminal (outside VS Code), or is it broken in both?
4. Claude Code comparison — you mention Claude Code can connect to Unity MCP. Is that the Claude Code CLI or the Claude Code VS Code extension? Sharing the working config would help us spot the difference.

---

Investigation (static analysis — reproduction not executed in CI)

Confidence: plausible (no reproduction available to confirm)

Similar issue: #3033 reported the same pattern — Unity MCP worked in the qwen CLI but not in the VS Code extension. That issue was closed without a visible fix, so the root cause may still be present.

How MCP connects in Qwen Code: the MCP client (packages/core/src/tools/mcp-client.ts) supports three transports — stdio (via command), SSE (via url), and Streamable HTTP (via httpUrl). Unity MCP typically uses stdio. The transport is selected from the config fields; if none match, the server fails with "Invalid configuration".

Likely root causes (without error output, these are hypotheses):

• Config not reaching the extension: the VS Code extension and the CLI may read MCP server configs from different paths. If Unity MCP is configured in a location only the CLI reads (e.g. ~/.qwen/settings.json vs the VS Code settings path), the extension won't see it.
• .mcp.json approval gate: project-scoped MCP servers declared in .mcp.json are held behind a pending-approval gate (pendingMcpServers in config). If Unity MCP was added via .mcp.json, it won't connect until explicitly approved.
• Windows PATH / environment: the stdio transport inherits a sanitized process.env with Windows PATH normalization (normalizePathEnvForWindows). If the Unity MCP command (e.g. npx, node, or a Unity-specific binary) isn't on the PATH visible to the VS Code extension process, the spawn will fail silently or with an ENOENT.
• Discovery timeout: stdio servers get a 30-second discovery handshake window by default. If Unity MCP's startup is slow (e.g. loading Unity project state), it could time out before tools are listed.

What would help most: the MCP server config entry and the error output (VS Code Output panel → Qwen Code channel, or qwen --debug logs if reproducible in CLI).

中文说明

• 类型: bug
• 标签: type/bug、scope/mcp、scope/vscode、category/integration、status/need-information
• 下一步: 需要报告者提供复现细节

感谢反馈！这个问题与 #3033 类似（Unity MCP 在 CLI 中可用但在 VS Code 扩展中不行）。为了排查，需要更多信息：

1. MCP 配置 — Unity MCP 是如何配置的？请提供 settings.json（或 .qwen/settings.json / .mcp.json）中相关的 mcpServers 配置。是 stdio 命令还是 HTTP/SSE URL？
2. 错误信息 — 尝试使用 Unity MCP 时具体发生了什么？服务器启动失败、工具未显示、还是工具显示但调用失败？VS Code 输出面板（Qwen Code 频道）中是否有错误信息？
3. CLI 与扩展 — 在终端中运行 qwen（不通过 VS Code）时 Unity MCP 是否可用？还是两边都不行？
4. Claude Code 对比 — 你提到 Claude Code 可以连接 Unity MCP。是 Claude Code CLI 还是 Claude Code VS Code 扩展？分享可用的配置有助于我们发现差异。

---

调查（静态分析 — CI 中未执行复现）

置信度：可能（无复现可确认）

类似问题：#3033 报告了相同模式——Unity MCP 在 qwen CLI 中可用但在 VS Code 扩展中不行。该 issue 已关闭但未见明确修复，根因可能仍然存在。

MCP 连接机制：MCP 客户端（packages/core/src/tools/mcp-client.ts）支持三种传输——stdio（通过 command）、SSE（通过 url）和 Streamable HTTP（通过 httpUrl）。Unity MCP 通常使用 stdio。传输方式由配置字段决定；如果没有匹配项，服务器会以 "Invalid configuration" 失败。

可能的根因（无错误输出，以下为假设）：

• 配置未传递到扩展：VS Code 扩展和 CLI 可能从不同路径读取 MCP 服务器配置。如果 Unity MCP 配置在仅 CLI 读取的位置（如 ~/.qwen/settings.json 与 VS Code 设置路径不同），扩展将看不到它。
• .mcp.json 审批门控：在 .mcp.json 中声明的项目级 MCP 服务器会被置于待审批门控后。如果 Unity MCP 是通过 .mcp.json 添加的，在明确批准之前不会连接。
• Windows PATH / 环境变量：stdio 传输继承经过清理的 process.env，并在 Windows 上进行 PATH 规范化。如果 Unity MCP 的命令（如 npx、node 或 Unity 特定二进制文件）不在 VS Code 扩展进程可见的 PATH 中，启动将静默失败或报 ENOENT。
• 发现超时：stdio 服务器默认有 30 秒的发现握手窗口。如果 Unity MCP 启动较慢（如加载 Unity 项目状态），可能在工具列出之前超时。

最需要的信息：MCP 服务器配置条目和错误输出（VS Code 输出面板 → Qwen Code 频道，或如果在 CLI 中可复现则使用 qwen --debug 日志）。

--- Qwen Code

[doudouOUC]

Thanks for reporting this. Based on the code, I think the most likely cause is an environment/PATH inheritance gap in the VS Code extension path.

When the VS Code extension spawns the CLI process (which then spawns MCP servers), it passes process.env as-is. If VS Code was launched from the GUI (not from a terminal via code .), the environment may be missing paths that Unity MCP's command depends on. This is a known pattern — the desktop Electron app has a dedicated loadShellEnv() step to resolve the full shell environment, but the VS Code extension currently does not.

A few things that would help narrow this down:

1. How is Unity MCP configured? Please share the mcpServers entry from your .mcp.json or VS Code settings (redact any secrets). In particular: what is the command value — is it a bare name like npx / node / unity-mcp, or an absolute path?

2. What error do you see? Check the MCP output channel in VS Code (Output panel → select "Qwen Code MCP" or similar). Is it ENOENT (command not found), a timeout, or something else?

3. Quick workaround to try: use the absolute path to the Unity MCP binary in your config, e.g.:

   {
     "mcpServers": {
       "unity": {
         "command": "C:\\full\\path\\to\\unity-mcp.exe",
         "args": ["..."]
       }
     }
   }

   If this makes it connect, it confirms the PATH resolution issue.

4. Another workaround: launch VS Code from a terminal (code .) so it inherits your full shell PATH.

If you can share the MCP config and the specific error output, we can confirm whether this is the PATH issue or something else (e.g., a transport/protocol mismatch with Unity MCP's server implementation).

[yiliang114]

@cowenchin Thanks for reporting this! One clarification: the Qwen Code VS Code extension does not use a separate MCP configuration. It starts the bundled CLI in ACP mode for the current workspace and reads the same Qwen configuration sources as the CLI, including ~/.qwen/settings.json, the workspace .qwen/settings.json, and .mcp.json. The empty mcpServers list sent in the ACP session/new request only means that VS Code is not injecting additional client-side MCP servers; it does not override or clear the file-based configuration.

Could you confirm whether Unity MCP works with Qwen Code CLI 0.21.0 when launched from the same workspace? Please also share the Unity MCP configuration entry, which file it is stored in, and the relevant output from the Qwen Code Companion output channel after reloading VS Code.

If the same CLI version works in the same workspace while the extension does not, that would largely rule out the configuration source and narrow the investigation to differences in the VS Code process environment/PATH. Temporarily using an absolute path for the MCP command would also help verify that.