Add project-scoped .mcp.json support with pending approval semantics

[qqqys]

What would you like to be added?

Add support for project-scoped .mcp.json MCP server configuration, with an explicit pending-approval state before any server is started or connected.

Suggested behavior:

• If a workspace contains .mcp.json, qwen mcp list can show its servers with a Pending approval status before the user has approved them.
• qwen mcp get <name> can show the server config and pending status.
• Pending project-scoped servers must not spawn stdio processes, attempt remote transport connections, or run health checks.
• Once the user explicitly approves a project-scoped server, it can use the normal connection and health-check behavior.
• The approval decision should bind to a canonicalized hash of the server config, not just the server name. If .mcp.json is later modified, the affected server returns to Pending approval and must be re-approved. This prevents a previously-approved name from being silently repointed to a different command/args/env or transport endpoint after approval. (Thanks to @Ram9199 for raising this.)
• Existing settings-based, CLI-provided, and extension-provided MCP configs should keep their current behavior unless they are moved under the new project-scoped approval model.

Why is this needed?

Qwen Code currently supports MCP servers from settings, --mcp-config, and extensions. A project-scoped .mcp.json would be useful for sharing MCP setup with a repository, but it has a different trust profile: the file comes from the workspace and may be untrusted.

Listing configured MCP servers is an inspection action. If project-scoped MCP config is added, inspecting it should remain side-effect-free until the user explicitly approves the server. This avoids executing workspace-controlled commands just because the user viewed MCP configuration.

Binding approval to a config hash closes a related gap: approval should be about the exact configuration the user reviewed, so any change to the underlying command, arguments, environment, or transport invalidates the prior approval rather than inheriting trust by name.

Additional context

This request is specifically about adding project-scoped .mcp.json support with safe default behavior. It should not imply that .mcp.json is already loaded today.

[qwen-code-ci-bot]

This appears related to existing MCP security and configuration issues:

• Feature Request: Add per-tool auto-approval for MCP servers #861 (closed) - Per-tool auto-approval for MCP servers - discusses granular control over MCP tool execution and security trade-offs between trust levels
• ${VAR} in settings.json headers not resolved from .env files env var substitution runs before .env is loaded #4466 (open) - Environment variable substitution in MCP server headers - addresses credential security in MCP configuration

Both touch on the security model for MCP server configuration and approval workflows.

[Ram9199]

@qqqys the pending-approval state before starting any project-scoped MCP server is the right security boundary.

I would treat .mcp.json as untrusted workspace input until approved, so even inspection should avoid side effects: no stdio spawn, no remote connection, no health check. The approval decision should ideally bind to a canonicalized server config hash, not just the server name, so a modified .mcp.json returns to pending.

Agent_Sudo is exploring this kind of scoped approval/delegation and audit model for MCP/tool execution if useful as a reference: https://github.com/Kisyntra/Agent_Sudo

[qqqys]

Thanks @Ram9199, fully agree on both points.

Treating .mcp.json as untrusted workspace input until approved — with no stdio spawn, no remote connection, and no health check during inspection — is exactly the boundary I want for this.

The config-hash binding is a great catch and closes a real gap: approval should attach to the exact configuration the user reviewed, not just the server name. Otherwise a previously-approved entry could be silently repointed to a different command/args/env or transport endpoint. I've folded this into the issue description: approval binds to a canonicalized hash of the server config, and any modification returns the affected server to Pending approval for re-approval.

Appreciate the Agent_Sudo reference too — I'll take a look at how it models scoped approval and audit.