Copilot CLI ignores `oauth.clientId` in mcp-config.json, always uses Dynamic Client Registration (DCR)

[skg-marimuthu]

Describe the bug

Copilot CLI ignores the oauth.clientId configured in ~/.copilot/mcp-config.json for remote HTTP MCP servers. Instead, it always performs Dynamic Client Registration (DCR) and uses a server-assigned client ID, even when a static clientId is explicitly provided.

Affected version

GitHub Copilot CLI 1.0.26

Steps to reproduce the behavior

1. Configure remote HTTP MCP servers in ~/.copilot/mcp-config.json with an explicit oauth.clientId:

{
  "mcpServers": {
    "WorkIQ-Calendar-MCP-Server": {
      "url": "https://agent365.svc.cloud.microsoft/.../mcp_CalendarTools",
      "type": "http",
      "oauth": {
        "clientId": "ba081686-5d24-4bc6-a0d6-d034ecffed87",
        "callbackPort": 8080
      }
    }
  }
}

2. Clear any cached OAuth state: Remove-Item ~/.copilot/mcp-oauth-config/* -Force
3. Start Copilot CLI: copilot
4. Observe the browser OAuth redirect URL — the client_id parameter is a DCR-assigned ID (aebc6443-996d-45c2-90f0-388ff96faa56), not the configured one (ba081686-...)
5. Inspect cached OAuth state in ~/.copilot/mcp-oauth-config/ — all entries show "isStatic": false and the DCR-assigned client ID

Expected behavior

When oauth.clientId is explicitly set in the MCP server config, the CLI should use that static client ID for the OAuth flow instead of performing Dynamic Client Registration (DCR).

This is important because:

• Organizations may have pre-registered OAuth applications with specific client IDs
• The DCR-assigned client ID may not have the correct permissions or consent grants
• Admin consent is typically granted to a specific client ID, not a dynamically registered one

Additional context

Browser redirect URL (showing wrong client_id):

https://login.microsoftonline.com/organizations/oauth2/v2.0/authorize?...&client_id=aebc6443-996d-45c2-90f0-388ff96faa56&...

Cached OAuth state (showing DCR was used):

{
  "clientId": "aebc6443-996d-45c2-90f0-388ff96faa56",
  "isStatic": false
}

Related issues:

• Support CIMD for Remote OAuth MCP Servers #1305 — Support CIMD for Remote OAuth MCP Servers
• Do not initiate redundant MCP OAuth Flows per server #2036 — Do not initiate redundant MCP OAuth flows per server (same clientId causes N auth prompts)

Proposed fix: When oauth.clientId is present in the server config, skip DCR and use the provided client ID directly with "isStatic": true. The oauth.callbackPort should also be respected to avoid the random port issue described in #1491.

[raye-deng]

This is a subtle but important bug — configuration being silently ignored in favor of a default behavior that may not be appropriate for the environment.

The security implication is significant: when you explicitly configure a with admin consent grants, but the tool silently uses a dynamically registered client ID instead, you're running with the wrong authorization scope. The DCR client might not have access to the resources you expect, or worse, might have access to resources it shouldn't.

What makes this particularly dangerous is that it's not a clear failure. The OAuth flow succeeds, the tool appears to work, and you don't discover the mismatch until you hit a permission error in production. By then, you've been operating with the wrong security context for who knows how long.

This pattern is representative of a broader class of AI-tool reliability issues: configuration drift where what you configured differs from what the tool actually uses. We see similar issues with:

• Environment variables being overridden by defaults
• API version headers being ignored in favor of "latest"
• Timeout settings falling back to hard-coded values

Traditional unit tests don't catch these because the tool interface is being used correctly — the bug is in the semantic layer where configuration should take precedence over defaults.

We've been adding validation to detect this class of issue — checking that explicitly configured settings are actually respected at runtime, and flagging when there's a mismatch between expected and actual behavior.

For OAuth specifically, it's critical that be treated as a hard override, not a hint. The difference between a static client with admin consent and a dynamic client is the difference between "this deployment has been approved" and "I have no idea who this is."

npx @opencodereview/cli scan . --sla L1