[BUG] MCP server named "supabase" ignores stdio configuration and forces SSE/OAuth connection

Resolved 💬 2 comments Opened Jan 28, 2026 by ImpactersDev Closed Feb 28, 2026

Preflight Checklist

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

What's Wrong?

When an MCP server is named "supabase" in .mcp.json, Claude Code ignores the user's stdio configuration and forces SSE/OAuth connection to https://mcp.supabase.com/mcp instead. Even with explicit "type": "stdio" in the configuration, Claude Code overrides it with built-in Supabase OAuth integration.

What Should Happen?

User configuration in .mcp.json should always take precedence over built-in OAuth integrations. When "type": "stdio" is explicitly set with a local command, Claude Code should use stdio transport regardless of the server name.

Error Messages/Logs

MCP server "supabase": SSE transport initialized, awaiting connection
MCP server "supabase": Starting connection with timeout of 30000ms
MCP server "supabase": Returning tokens
MCP server "supabase": Token length: 50
MCP server "supabase": Has refresh token: true
MCP server "supabase": Expires in: 86096s
MCP server "supabase": SSE Connection failed after 363ms: {"url":"https://mcp.supabase.com/mcp","error":"SSE error: Non-200 status code (405)"}

Steps to Reproduce

**1. Install @supabase/mcp-server-supabase locally with its dependencies

  1. Configure .mcp.json:**

{
"mcpServers": {
"supabase": {
"type": "stdio",
"command": "/usr/local/bin/node",
"args": [
"/path/to/node_modules/@supabase/mcp-server-supabase/dist/transports/stdio.js",
"--project-ref=<project-ref>"
],
"env": {
"SUPABASE_ACCESS_TOKEN": "<token>"
}
}
}
}

**3. Start Claude Code

  1. Run /mcp - connection fails**

Workaround: Rename server to "supabase-local" - then stdio works correctly.

Claude Model

Opus

Is this a regression?

Yes, this worked in a previous version

Last Working Version

It doesn't seem to work well around 26.01.26-27. There was no problem before that.

Claude Code Version

2.0.67

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

VS Code integrated terminal

Additional Information

Troubleshooting attempts before discovering the root cause:
We went through extensive debugging before identifying that the server name "supabase" was the issue:

  1. Cleared npx cache (rm -rf ~/.npm/_npx) - multiple times
  2. Fixed missing zod dependency - @supabase/mcp-server-supabase has a bundling bug where zod is not included; manually installed it
  3. Installed package locally - Created ~/.mcp-servers/supabase/ and ran npm install @supabase/mcp-server-supabase zod
  4. Changed from npx to direct node execution - To bypass npx cache issues
  5. Fixed entry point path - Discovered the correct entry point is dist/transports/stdio.js, not dist/index.js
  6. Used absolute path for node - Changed "command": "node" to "command": "/usr/local/bin/node"
  7. Regenerated Supabase access token - Old token had expired (API returned 401)
  8. Added explicit "type": "stdio" - To force stdio transport
  9. Verified MCP server works manually - JSON-RPC test returned valid response with 20+ tools
  10. Finally renamed server to "supabase-local" - This was the only solution that worked

Key findings:

  • The local MCP server works correctly when tested manually via JSON-RPC
  • Supabase API token is valid (confirmed with curl returning HTTP 200)
  • The issue is specifically triggered by the server name "supabase" - renaming to any other name allows stdio configuration to be respected
  • Claude Code appears to have hardcoded Supabase OAuth handling that completely overrides user configuration, ignoring even explicit "type": "stdio"

View original on GitHub ↗

This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗