fix(mcp): restore trust+isTrustedFolder permission check in getDefaultPermission

[huww98]

TLDR

The trust: true setting on MCP servers stopped working in v0.13.0 after the permission system refactor (PR #2283). This PR restores the original behavior.

Screenshots / Video Demo

• Above: this PR, auto allow
• Below: v0.13.0, ask

Dive Deeper

Root Cause

PR #2283 (feat/support-permission) refactored MCP tool confirmation from the old shouldConfirmExecute() API to the new getDefaultPermission() + getConfirmationDetails() split.

The original shouldConfirmExecute() had an explicit trust check:

if (this.cliConfig?.isTrustedFolder() && this.trust) {
  return false; // server is trusted, no confirmation needed
}

The refactored getDefaultPermission() omitted this check entirely, leaving only a comment: "Note: trust/isTrustedFolder logic is now handled by PM rules". However, no PM rules were ever generated from the trust setting, making trust: true completely non-functional — the field is stored, passed through the entire config → mcp-client → DiscoveredMCPTool → Invocation chain, but never consulted during permission evaluation.

Fix

Restore the original two-condition check in getDefaultPermission():

• trust === true on the MCP server config
• isTrustedFolder() on the workspace (security gate)

Both conditions must be true, preserving the security invariant that trust settings (including user-level ~/.qwen/settings.json) cannot bypass confirmation in untrusted workspaces.

Reviewer Test Plan

Add to your project's .qwen/settings.json (trusted workspace):

{
  "mcpServers": {
    "my-server": {
      "command": "...",
      "trust": true
    }
  }
}

MCP tools from my-server should now execute without a confirmation dialog. Before this fix they always prompted regardless of the trust setting.

Testing Matrix

	🍏	🪟	🐧
npm run	✅	❓	❓
npx	❓	❓	❓
Docker	❓	-	-
Podman	❓	-	-
Seatbelt	❓	-	-

Linked issues / bugs

Related to #861

---

🤖 Generated with Qoder

[LaZzyMan]

LGTM!