Where does the bug appear (feature/product)?
Cursor IDE
Describe the Bug
Few days ago my local mcp connection to Fibery died and can’t be restored.
Not sure what caused it but thing worth noting:
- around that time I was setting up cloud agents and started using Agents Window more.
- I have two cursor accounts. For second I have a macos alias that supplies a different user-dir. Both accs required different auth for Fibery
Steps to Reproduce
Add to mcp.json:
"Fibery": {
"url": "https://mcp.fibery.io/mcp"
}
Expected Behavior
should connect without errors
Screenshots / Screen Recordings
cursor-fibery-mcp-bug-report.zip (22.5 KB)
Operating System
MacOS
Version Information
Version: 3.16.29
VS Code Extension API: 1.128.0
Commit: 6246455961129c32969845e00aa25d87ae926ec0
Date: 2026-08-18T01:26:26.285Z
Layout: Agent Window
Build Type: Stable
Release Track: Default
Electron: 40.10.3
Chromium: 144.0.7559.236
Node.js: 24.15.0
V8: 14.4.258.32-electron.0
xterm.js: 6.1.0-beta.291
OS: Darwin arm64 25.5.0
Additional Information
Report generated by grok:
Bug: Local HTTP MCP to mcp.fibery.io fails with fetch failed; Cloud works; stdio mcp-remote workaround works
Environment
- Cursor: 3.16.29 (stable)
- Commit:
6246455961129c32969845e00aa25d87ae926ec0 - Date: 2026-08-18T01:26:26.285Z
- VS Code engine: 1.128.0
- Electron: 40.10.3 / Chrome 144.0.7559.236
- OS: macOS 26.5.2 (25F84), arm64
- System proxy: none (
scutil --proxyhas no HTTP/HTTPS proxy enabled) - Cursor
http.fetchAdditionalSupport: not set (default)
Config that fails (native Streamable HTTP)
"Fibery": {
"url": "https://mcp.fibery.io/mcp",
"headers": {}
}
UI: Settings → Tools & MCP → Configure Fibery
- Local:
Error · fetch failed(Logout / Show Output; no Login button) - Cloud:
Connected
Config that works (workaround)
"Fibery": {
"command": "npx",
"args": ["-y", "mcp-remote", "https://mcp.fibery.io/mcp"]
}
Same host, same machine. mcp-remote 0.1.37 connects via Node TLS / stdio and then OAuth succeeds.
Expected
Native HTTP MCP should connect (or at least reach 401 + WWW-Authenticate and show Login), same as Figma MCP on this machine and same as Fibery MCP in Cloud.
Actual
Local Chromium McpProxyFetch dies before an HTTP status is returned. Error is only fetch failed — the underlying net::ERR_* / TLS reason is not logged.
From mcpprocess.log (2026-08-19 14:50:45):
connecting streamableHttp for "Fibery" (user-Fibery)
[McpProxyFetch] Built VS Code proxy-aware MCP fetch for user-Fibery ... (origin: https://mcp.fibery.io)
WARN MCP HTTP exchange failed
WARN Transient error connecting to streamableHttp server: fetch failed
Elapsed ~80–245ms (not a timeout). Repeats forever. Logout does not recover: reconnect still fetch failed, UI can stick on Connecting…
Contrast: Figma HTTP MCP on the same process gets a completed HTTP exchange and needsAuth:
connecting streamableHttp for "Figma" (user-Figma)
MCP HTTP exchange completed
MCP OAuth redirect
Connect failed after auth_required; returning needsAuth (streamableHttp)
Sentry / GitLab HTTP MCP also connect natively.
Same host is fine outside Cursor Chromium fetch
From this Mac, no VPN:
| Client | Result |
|---|---|
curl HTTP/2 POST https://mcp.fibery.io/mcp |
401 invalid_token / Missing Authorization header |
curl --http1.1 |
401 |
Node 24 fetch / https.request |
401, authorized=true |
OpenSSL s_client -verify_return_error |
Verify return code: 0 (ok) |
Cursor local McpProxyFetch |
fetch failed |
| Cursor Cloud MCP | Connected |
Cursor stdio mcp-remote |
Connected |
DNS: mcp.fibery.io → fibery-cluster.fibery.io → aws-stable-cluster.fibery.io → 18.198.38.11, 18.192.171.63, 3.64.96.241 (eu-central-1). No HTTP(S) proxy. No IPv6 AAAA on the leaf name that curl needed.
TLS chain of mcp.fibery.io
Server presents 2 certificates (leaf + intermediate, no root):
- Leaf:
CN=*.fibery.io(SAN:*.fibery.io,fibery.io)- Issuer: Go Daddy Secure Certificate Authority - G2
- Not before: 2026-03-09, not after: 2026-09-23
- Intermediate: Go Daddy Secure Certificate Authority - G2
- Issuer: Go Daddy Root Certificate Authority - G2
- 2011-05-03 → 2031-05-03
macOS SystemRootCertificates has Go Daddy Root G2. openssl verify of leaf+intermediate: OK (depth 2 root from the OS store).
Working Figma MCP cert is Amazon RSA 2048 M04, not GoDaddy.
Why VPN will not fix this
The host is reachable on the current path. Node/curl/OpenSSL already succeed without a VPN. Cloud succeeding only shows that Cursor’s cloud MCP runtime can talk to the same URL; it does not mean the local Chromium fetch is blocked by IP/geo. A VPN would not change Cursor’s MCP TLS stack or CA store. A TLS-inspecting VPN would more likely make it worse.
Secondary UX bugs
- Agent
mcp_authonuser-Fiberyshows a Login prompt, then Cursor kills the tool call at 30s, and the prompt disappears. - After native fetch failure, UI still shows Logout (stale local tokens) and never surfaces Login, because the request never gets to
401/auth_required. - Failure is logged as generic
fetch failedwith nocause/net::ERR_CERT_*. Related public reports for Fibery MCP in Cursor showunable to get issuer certificatefor this same GoDaddy chain.
Related
- MCP error. fetch failed: unable to get issuer certificate (Fibery MCP, GoDaddy, Cursor cannot verify issuer)
- Cursor seems to me missing some CA certificates? (Can't connect to some HTTPS servers)
Attachments in this folder
logs/mcp-server-user-Fibery.log— repeatingfetch failed, then stdio success after workaroundlogs/mcpprocess.log—McpProxyFetchforhttps://mcp.fibery.iologs/mcp-server-user-Figma.log— native HTTP MCP working (control)certs/leaf.pem,certs/intermediate-godaddy-secure-g2.pemopenssl-verify.txt,node-tls.txt,contrast-fibery-vs-figma.txt
Does this stop you from using Cursor
Sometimes - I can sometimes use Cursor
