Issue Station
Sign In
Tools hereToolbox

claude-code - 💡(How to fix) Fix [BUG] Plugin MCP with type:http proxied through claude.ai in Desktop app — breaks VPN/internal servers [1 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
anthropics/claude-code#52749•Fetched 2026-04-24 10:40:37
View on GitHub
Comments
0
Participants
1
Timeline
5
Reactions
0
Author
bmSebastiansbmSebastians
Participants
bmSebastiansbmSebastians
Timeline (top)
labeled ×5

Error Message

Error Messages/Logs

Code Example



---

{
           "mcpServers": {
             "my-server": {
               "type": "http",
               "url": "https://internal-mcp-server.example.com/mcp"
             }
           }
         }
RAW_BUFFERClick to expand / collapse

Preflight Checklist

  • I have searched existing issues and this hasn't been reported yet
  • This is a single bug report (please file separate reports for different bugs)
  • I am using the latest version of Claude Code

What's Wrong?

Description

Plugin MCP servers configured with "type": "http" in .mcp.json connect directly from the user's machine in the CLI, but are proxied through claude.ai infrastructure in the Claude Code Desktop app (Windows). This means any MCP server behind a VPN or on an internal network works in the CLI but fails in the Desktop app, since claude.ai cannot reach the internal endpoint.

Plugin .mcp.json

{ "mcpServers": { "mcp-name": { "type": "http", "url": "https://mcp-internal.example.com/mcp" } } }

The server implements full MCP spec: Streamable HTTP transport, OAuth discovery (.well-known/oauth-authorization-server), dynamic client registration, PKCE — all verified working via curl and the CLI.

What Should Happen?

The Desktop app should respect "type": "http" in plugin .mcp.json and connect directly from the user's machine, exactly like the CLI does.

Error Messages/Logs

Steps to Reproduce

  1. Set up an MCP server on an internal network (behind VPN) with Streamable HTTP transport and OAuth discovery 2. Create a plugin in a GitHub-hosted marketplace with this .mcp.json: json { "mcpServers": { "my-server": { "type": "http", "url": "https://internal-mcp-server.example.com/mcp" } } } 3. Add the marketplace to Claude Code settings (extraKnownMarketplaces or via /plugin) 4. Install the plugin in both CLI and Desktop app 5. In the CLI: run /mcp → authenticate → MCP connects successfully as plugin:my-server:my-server (direct connection from local machine) 6. In the Desktop app: go to Customize > Plugins/Connectors → click Connect on the same plugin → fails with "Server not found" or "Failed to connect"

Claude Model

Other

Is this a regression?

No, this never worked

Last Working Version

No response

Claude Code Version

2.1.108

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

No response

extent analysis

TL;DR

The Desktop app should be modified to respect the "type": "http" configuration in plugin .mcp.json and connect directly to the MCP server from the user's machine.

Guidance

  • Verify that the MCP server is correctly configured with Streamable HTTP transport and OAuth discovery, as the issue may be related to the server setup.
  • Check the .mcp.json file for any typos or incorrect configurations, ensuring that the type is set to "http" and the url points to the correct internal MCP server endpoint.
  • Consider implementing a proxy bypass or direct connection mechanism in the Desktop app for MCP servers with "type": "http" to match the CLI behavior.
  • Test the connection using the CLI to confirm that the issue is specific to the Desktop app.

Example

No code snippet is provided as the issue is related to the application's behavior and configuration rather than a specific code error.

Notes

The issue may be related to the Desktop app's architecture or networking configuration, which could be limiting direct connections to internal MCP servers. Further investigation into the app's code and networking setup may be necessary to resolve the issue.

Recommendation

Apply a workaround by modifying the Desktop app to connect directly to the MCP server from the user's machine when "type": "http" is specified in the plugin .mcp.json, to match the behavior of the CLI.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…
#api#memory optimization#batch processing#GPU compatibility#latency issue

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

claude-code - 💡(How to fix) Fix [BUG] Plugin MCP with type:http proxied through claude.ai in Desktop app — breaks VPN/internal servers [1 participants]