Support Perplexity custom connectors (MCP Streamable HTTP) — POST /api/mcp rejects valid API keys with 401 / clients see HTTP 419 #288

Activity

1. fieldmanneasi

   added

   bugSomething isn't workingSomething isn't working

   on May 2, 2026
2. link-webcreations commented on Jul 6, 2026

   

   link-webcreations

   on Jul 6, 2026

   More actions

   Hello,

   I have the same error, but using VS-Code / Github Copilot:

   2026-07-06 10:37:56.148 [info] Starting server pascal
   2026-07-06 10:37:56.148 [info] Connection state: Starting
   2026-07-06 10:37:56.150 [info] Starting server from Remote extension host
   2026-07-06 10:37:56.162 [info] Connection state: Running
   2026-07-06 10:37:58.814 [info] Discovered 46 tools
   2026-07-06 10:37:59.307 [info] Connection state: Error 419 status sending message to https://editor.pascal.app/api/mcp: {"jsonrpc":"2.0","error":{"code":-32001,"message":"MCP session expired or moved to another server instance. Reinitialize, then call get_project_status with your projectId to re-bind and continue from the browser-visible draft."},"id":null}
   

   With this configuration:

   {
     "inputs": [
       {
         "id": "pascal_api_key",
         "type": "promptString",
         "description": "Pascal Editor MCP API Key",
         "password": true
       }
     ],
     "servers": {
       "pascal": {
         "url": "https://editor.pascal.app/api/mcp",
         "headers": {
           "Authorization": "Bearer ${input:pascal_api_key}"
         }
       }
     }
   }
3. Aymericr commented on Jul 19, 2026

   

   Aymericr

   on Jul 19, 2026

   Contributor

   More actions

   Current triage: the May report and the July comment expose two distinct hosted-endpoint failures. The original initialize request returns 401 before a session exists; the later client discovers tools and then gets the explicit 419 session-expired response, which means initialization succeeded but a subsequent request reached an instance that did not own the in-memory session. Neither is implemented in the public @pascal-app/mcp package itself; both are hosted editor.pascal.app transport/auth behavior. Keeping this open, but please include a fresh initialize curl response and response headers when retesting so the auth failure and cross-instance session-affinity failure are not conflated.
4. Aymericr commented on Aug 4, 2026

   

   Aymericr

   on Aug 4, 2026

   Contributor

   More actions

   I traced both reports through the hosted endpoint. They are two different failures, and neither lives in the open-source @pascal-app/mcp package — both are in the hosted /api/mcp route on editor.pascal.app. Writing up the mechanisms so the fix is reviewable, and so anyone hitting this has a workaround today.

   @link-webcreations' 419 (Discovered 46 tools, then Error 419) — statelessness, not expiry.

   The route keeps sessions in a module-level Map (const sessions = new Map<string, McpSession>()), created on initialize via onsessioninitialized and looked up by the mcp-session-id header on every subsequent request. On a serverless platform each request can land on a different instance, and that Map isn't shared between them. So the sequence in your log is exactly: initialize lands on instance A and registers the session → tools/list also hits A (hence "Discovered 46 tools") → the next request routes to instance B, where sessions.get(sessionId) misses, sessionId is truthy, and the handler returns our explicit 419 with the "session expired or moved to another server instance" message. The SESSION_TTL_MS of 2h is a red herring; this fires seconds after a successful handshake. It's also why Claude Code/Cursor/Codex appear to "work fine" — they do, until a request happens to land elsewhere, so it presents as intermittent rather than broken.

   The real fix is to stop holding transport state in process memory: rehydrate the session from durable storage per request (the API key already identifies the user, and get_project_status already re-binds the scene). That's a hosted-side change I'm scoping now; the 419 message itself is honest and the client-side recovery it names does work.

   The original 401 on POST initialize — the GET/POST asymmetry is a false signal.

   Worth correcting the premise, because it points somewhere misleading: the GET /api/mcp that returns the 200 descriptor never validates your key at all. When the request isn't an MCP stream request, the handler returns the static discovery JSON before any auth runs. So "the key works on GET and fails on POST" isn't a POST-specific auth bug — GET simply never checked. Both methods go through the same resolveAuth once you're on the MCP path.

   The 401 body you saw ({"error":"unauthorized","message":"Invalid or revoked API key."}) is emitted from exactly one branch: the token started with sk_live_/sk_test_ and verifyApiKey returned null. That happens when the SHA-hash lookup misses, or the record is revoked, or expiresAt has passed, or — the one I'd bet on for a connector — the key is org-scoped and the owner's membership is gone, which returns null even though the key itself is valid and unexpired. If the token doesn't match either prefix you'd get the other 401 message ("Provide a Bearer API key…"), so we can rule out truncation or a mangled Authorization header from your report.

   Two things worth checking, @fieldmanneasi:

   1. Confirm the key still appears unrevoked in Settings → API keys, and whether it was created under a workspace/organization you've since left.
   2. Bearer parsing is case-insensitive and takes everything after the first whitespace run, so a trailing newline from a copy-paste would be included in the hash and cause exactly this 401. Re-creating the key and pasting without a trailing newline is the cheapest thing to try.

   Also relevant to Perplexity specifically: there's an Origin-based guard that 403s any request whose Origin header isn't same-origin, loopback, or in PASCAL_SCENE_API_ORIGINS, and a 120 req/min per-IP rate limit that returns 429. Neither produces a 401, so they're not your failure — but a server-to-server connector calling from shared infrastructure could plausibly trip the rate limit, and I'm adding both to the docs since today they're invisible to clients.

   Status. Keeping this open and treating the stateless-session fix as the primary work, since it's the one that makes every Streamable HTTP client reliable rather than intermittently working. I'll report back here when it ships. Thanks both for the precise logs — the "discovered 46 tools then 419" line is what made the instance-affinity cause unambiguous.
5. Aymericr

   added

   ready-for-humanNeeds human input during executionNeeds human input during execution

   on Sep 12, 2026