[FEATURE] VSCode Extension: Add SSE transport support for MCP servers (already supported in CLI)

[AsiaOstrich]

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet
• [x] This is a single feature request (not multiple features)

Problem Statement

I need to use a custom MCP server (knowledgeforge-rag) that runs on a remote machine and uses SSE (Server-Sent Events) transport. This server is accessible via SSH tunnel at http://localhost:8090/sse.

Current Situation:

• The Claude CLI can connect to this SSE-based MCP server successfully
• The VSCode Claude Code extension fails with error: "SSE MCP servers are currently not supported in native builds"
• This forces me to switch between VSCode and terminal, breaking my integrated workflow

Impact on Workflow:

• I cannot access my knowledge base from within VSCode
• I must context-switch to terminal to run claude --print commands
• This disrupts the seamless development experience that Claude Code provides
• stdio-based MCP servers (excel, word, powerpoint) work fine, but SSE servers don't

Why This Matters: SSE transport is essential for remote MCP servers, especially those behind SSH tunnels or deployed on separate machines. This creates feature disparity between CLI and VSCode extension.

Proposed Solution

Add SSE transport support to the VSCode Claude Code extension, matching the existing CLI capabilities.

Ideal User Experience:

1. Configuration: Users can define SSE MCP servers in .mcp.json: { "mcpServers": { "knowledgeforge-rag": { "type": "sse", "url": "http://localhost:8090/sse" } } }

2. Connection: When VSCode reloads, the extension connects to SSE servers just like stdio servers

3. Status: The /mcp command shows SSE servers as "connected" alongside stdio servers:

   • excel (stdio): ✅ Connected
   • word (stdio): ✅ Connected
   • knowledgeforge-rag (sse): ✅ Connected

4. Usage: Users can interact with SSE-based MCP tools seamlessly within VSCode, without needing to switch to terminal

Technical Implementation:

• Reuse the existing SSE transport implementation from Claude CLI
• Ensure proper error handling for network issues
• Support authentication headers if needed (similar to CLI's -H flag)

Alternative Solutions

Current Workaround: Using Claude CLI in terminal: claude --print "query using knowledgeforge"

Limitations:

• Breaks VSCode workflow integration
• Cannot use MCP tools in the natural conversation flow
• Must copy/paste results between terminal and VSCode
• Loses context of the current file/project

Other Alternatives Considered:

1. Converting to stdio transport: Would require significant server-side changes and doesn't work for remote servers
2. HTTP proxy wrapper: Added complexity and latency
3. Waiting for SSH port forwarding improvements: Not a real solution to the core problem

None of these alternatives provide the seamless experience that native SSE support would offer.

Priority

High - Significant impact on productivity

Feature Category

MCP server integration

Use Case Example

Scenario: Knowledge-Enhanced Development

Setup:

• I maintain a custom knowledge base (knowledgeforge-rag) on a remote server (100.72.185.20)
• I connect via SSH tunnel: ssh -i ~/.ssh/id_mcp_knowledgeforge -L 8090:localhost:8090 -N -f [email protected]
• The server runs on port 8090 with SSE endpoint at /sse

Current Workflow (Broken):

1. I'm working in VSCode on a project file
2. I need to query my knowledge base about system architecture
3. Claude Code shows knowledgeforge-rag: ❌ failed in /mcp status
4. I must switch to terminal and run claude --print "explain IWSE system architecture"
5. I copy the response back to VSCode
6. Context is lost between terminal and editor

Desired Workflow (With SSE Support):

1. I'm working in VSCode on a project file
2. I ask Claude Code: "Query the knowledge base about IWSE system architecture"
3. Claude Code uses the knowledgeforge-rag MCP server seamlessly
4. I get the response directly in the conversation
5. I can continue working without context switching

Step-by-Step:

1. Configure .mcp.json with SSE server URL
2. Reload VSCode window
3. Verify /mcp shows knowledgeforge-rag as connected ✅
4. In Claude Code chat, naturally ask questions that trigger MCP tools
5. Claude Code calls the SSE-based MCP server in the background
6. Results appear inline in the conversation
7. Development continues seamlessly

Additional Context

Evidence:

1. CLI Works Successfully: $ claude mcp list knowledgeforge-rag: http://localhost:8090/sse (SSE) - ✓ Connected $ claude mcp get knowledgeforge-rag knowledgeforge-rag: Status: ✓ Connected Type: sse URL: http://localhost:8090/sse

2. Server Responds Correctly: $ curl -H "Accept: text/event-stream" http://localhost:8090/sse event: endpoint data: /messages/?session_id=51558452b48b409f82e0ac0c277ce6aa

3. VSCode Extension Error: From Developer Tools Console: [ERROR] MCP server "knowledgeforge-rag" Connection failed: SSE MCP servers are currently not supported in native builds.

Environment:

• OS: macOS (Darwin 24.6.0)
• VSCode: September 2025 (version 1.105), Release date: October 9, 2025
• Claude Code Extension: 2.0.14
• Claude CLI: Latest (SSE support confirmed working)

Technical Considerations:

• SSE is a W3C standard (Server-Sent Events)
• Long-lived HTTP connections with event stream
• Already implemented in Claude CLI codebase
• Similar to WebSocket but simpler (unidirectional)

Related Information:

• Issue #381 confirms SSE support was added to CLI in v0.2.54
• No existing issue found for VSCode extension SSE support
• This creates feature parity between CLI and VSCode extension

[github-actions[bot]]

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/5826
2. https://github.com/anthropics/claude-code/issues/7290
3. https://github.com/anthropics/claude-code/issues/1663

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

[AsiaOstrich]

This is NOT a duplicate

Thank you for the review, but this issue is fundamentally different from the suggested duplicates:

Why this is unique:

My Issue (#9522):

• Explicit error: SSE MCP servers are currently not supported in native builds
• Platform: VSCode Extension (native builds)
• Nature: Feature gap - SSE is intentionally not implemented
• Evidence: CLI supports SSE ✅, VSCode native builds don't ❌

vs. Suggested Duplicates:

1. #5826 - Different product entirely

   • Platform: Claude Desktop (not VSCode extension)
   • Issue: Connection/authentication failures
   • Not about SSE support

2. #1663 - Different symptom

   • Issue: Infinite hang/timeout on SSE connection
   • Implies SSE is supported but has a bug
   • My issue: SSE is explicitly not supported (error message states this)

3. #7290 - Different problem domain

   • Issue: Authentication headers being ignored
   • Implies SSE works but auth doesn't
   • My issue: SSE transport itself is not implemented

The Core Difference:

Other issues: SSE implemented but broken (bugs to fix) This issue: SSE not implemented at all (feature to add)

Supporting Evidence:

1. Explicit "not supported" error: [ERROR] MCP server "knowledgeforge-rag" Connection failed: SSE MCP servers are currently not supported in native builds.

2. CLI vs VSCode disparity:

• CLI: claude mcp list shows SSE server ✅ Connected
• VSCode: Same config fails with "not supported"

3. stdio works, SSE doesn't:

• excel (stdio): ✅ Connected
• word (stdio): ✅ Connected
• knowledgeforge-rag (sse): ❌ Not supported

This is a feature request to add SSE transport support to VSCode native builds, achieving feature parity with the CLI.

Please keep this issue open as it represents a distinct feature gap, not a duplicate bug.

[calebpriester]

Following. Would love to use this with JIRA for instance.

[babak-ironapi]

Experiencing the same issue with remote SSE MCP server

I'm hitting this exact problem with a production remote SSE MCP server (GenMem - centralized memory/knowledge server at https://mcp-memories.ironapi.com).

Current Status

✅ Works perfectly in Claude Desktop:

• Connects successfully via SSE transport
• Tools discovered: GenMem:search_memories_semantic, GenMem:store_memory_with_embedding
• All functionality works as expected
• Configuration: {"type": "sse", "url": "https://mcp-memories.ironapi.com/sse?apikey=..."}

✅ Works perfectly in claude.ai web interface:

• Same configuration, works flawlessly
• Full tool access and invocation

❌ Fails in Claude Code CLI (v2.0.50):

Attempted multiple configuration approaches:

Approach 1: Direct HTTP configuration in ~/.claude.json

{
  "mcpServers": {
    "GenMem": {
      "type": "http",
      "url": "https://mcp-memories.ironapi.com/sse?apikey=..."
    }
  }
}

Result: JSON Parse error: Unrecognized token '<'. Raw body: <html> - Server returns HTML instead of JSON-RPC

Approach 2: Using mcp-remote wrapper in .mcp.json

{
  "GenMem": {
    "command": "npx",
    "args": ["-y", "mcp-remote", "https://mcp-memories.ironapi.com/sse?apikey=..."]
  }
}

Result:

• claude mcp list shows: ✓ Connected
• /mcp in Claude Code shows: ✓ connected
• BUT: Zero tools discovered (should be 2)
• Tool invocation fails: Error: No such tool available: mcp__GenMem__search_memories_semantic

Approach 3: CLI-added HTTP transport

claude mcp add --transport http --scope user GenMem \
  "https://mcp-memories.ironapi.com/sse?apikey=..."

Result: (HTTP) - ✗ Failed to connect

Use Case

Why this matters:

I need centralized memory/knowledge accessible across:

• 💻 Desktop (Claude Desktop app) - ✅ works
• 📱 Mobile (iPhone Claude app) - ✅ works
• ⌨️ CLI/Terminal (Claude Code) - ❌ broken

Remote SSE is the only architecture that enables this cross-platform access. stdio transport would require local server instances, defeating the purpose of centralized, always-accessible memory.

Technical Evidence

The server is production-ready and serves other Claude clients successfully:

# Server responds correctly to SSE requests
$ curl -H "Accept: text/event-stream" https://mcp-memories.ironapi.com/sse?apikey=...
# Returns proper SSE event stream

# Claude Desktop config (works perfectly)
{
  "mcpServers": {
    "GenMem": {
      "type": "sse",
      "url": "https://mcp-memories.ironapi.com/sse?apikey=..."
    }
  }
}

Impact

This limitation prevents:

1. Unified workflows - Must switch between Claude Desktop and Claude Code depending on whether memory access is needed
2. Mobile + CLI integration - Can't leverage the same memory from terminal that's accessible on mobile
3. Enterprise deployments - Organizations can't deploy centralized MCP services usable across all Claude clients
4. Feature parity - Claude Code advertises MCP support but can't access the same servers Claude Desktop uses

Related Issues

This appears to be the same root cause as:

• #1663 - Infinite hang with mcp-remote and Atlassian SSE
• #3423 - Windows remote MCP server failures with child process termination
• #1387 - Request for streamable HTTP MCP server support

All point to incomplete SSE/remote server support in Claude Code.

Request

Please add native SSE transport support to Claude Code CLI to achieve feature parity with Claude Desktop. The capability clearly exists in the codebase (Claude Desktop works perfectly) - it just needs to be enabled in the CLI.

Current workaround: Use Claude Desktop when memory/remote MCP access is needed, use Claude Code for local filesystem work. Not ideal but functional.

Priority: High - This breaks legitimate production use cases where remote, always-available MCP servers are essential.

---

Environment:

• Claude Code: v2.0.50
• OS: macOS
• Subscription: Claude Max
• MCP Server: Production SSE server (https://mcp-memories.ironapi.com)

Happy to provide additional debugging info, server logs, or test access if it would help resolve this.

[github-actions[bot]]

This issue has been inactive for 30 days. If the issue is still occurring, please comment to let us know. Otherwise, this issue will be automatically closed in 30 days for housekeeping purposes.