Postman MCP plugin stuck on infinite "Authenticating..." state

Support Bug Reports
,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Postman MCP plugin stuck on infinite “Authenticating…” state

Hi everyone,

I’m having an issue with the Postman MCP plugin in Cursor.

When I try to authenticate, the authorization flow starts normally (Postman permission screen shows up), but after accepting, the plugin gets stuck in an infinite “Authenticating…” state and never completes.

I’ve attached screenshots for reference.

Some extra context:

Other MCP/plugins (like Notion and Figma) are working fine
This seems specific to Postman MCP
The authorization popup appears correctly, but the callback/finish step never resolves

Questions:

Is this a known issue?
Is anyone else able to authenticate successfully with Postman MCP?
Any workaround or something I might be missing?

Thanks!

Steps to Reproduce

  1. Go to Cursor (v3)
  2. Open the Marketplace
  3. Search for the Postman MCP plugin
  4. Install the plugin
  5. Attempt to authenticate

Screenshots / Screen Recordings

c1.png
c1.png743×699 40.5 KB

Operating System

Windows 10/11

Version Information

Cursor version: 3.0.13

Does this stop you from using Cursor

No - Cursor works, but with this issue

5

Hey, thanks for the report. This is a known issue. The MCP OAuth flow doesn’t always finish the token exchange correctly after the authorization callback. It affects a few providers, not just Postman.

A couple things to try:

  1. Uninstall the Postman MCP plugin, restart Cursor, then install it again.
  2. Make sure you only have one Cursor window open during authentication. Multi-window can cause a race condition with the OAuth callback.
  3. Try closing all Postman tabs in your browser before starting the auth flow.

If that doesn’t help, please share the logs from the Output panel: View > Output, then select MCP in the dropdown. This will help us see which step it’s stuck on, like timeout, 404, or PKCE mismatch.

The team is aware of this class of issues. Your report helps us prioritize it. Let me know how it goes.

7

Hi there, got the same problem today using cursor v3.1.14 on Mac. If I using Chrome as my default browser, then the authentication page can’t jump back to the cursor; and after I change into safari as the default browser, the postman plugin also stuck on infinite “Authenticating” state. I open the output and check the “MCP:plugin-postman-postman”, it shows:

2026-04-15 12:56:58.369 [info] MCP OAuth redirect to authorization
2026-04-15 12:56:58.375 [info] Stored server URL for OAuth flow
2026-04-15 12:56:58.375 [info] OAuth provider needs auth callback during connection
2026-04-15 12:56:58.376 [info] Connect failed after auth_required; returning needsAuth (streamableHttp)
2026-04-15 12:56:58.376 [info] MCP OAuth needsAuth (v2)
2026-04-15 12:56:58.377 [info] ReloadClient completed, connected: false, statusType: needsAuth
2026-04-15 12:57:20.496 [info] Received OAuth callback with code
2026-04-15 12:57:22.293 [info] Using attempt-scoped OAuth client information for callback flow
2026-04-15 12:57:22.297 [info] Using redirect URL
2026-04-15 12:57:22.920 [info] MCP OAuth tokens persisted
2026-04-15 12:57:22.924 [info] tokens() returning OAuth tokens
2026-04-15 12:57:22.925 [info] MCP OAuth callback exchange completed
2026-04-15 12:57:22.929 [info] [V2] Handling ReloadClient action
2026-04-15 12:57:22.929 [info] [V2 FSM] connection:connect_start: conn=idle,auth=unknown -> conn=connecting,auth=unknown
2026-04-15 12:57:23.531 [info] tokens() returning OAuth tokens
2026-04-15 12:57:25.327 [info] Returning stored OAuth client_id
2026-04-15 12:57:25.328 [info] Using redirect URL
2026-04-15 12:57:25.329 [info] tokens() returning OAuth tokens
2026-04-15 12:57:26.425 [info] MCP OAuth tokens persisted
2026-04-15 12:57:26.425 [info] MCP OAuth refresh succeeded
2026-04-15 12:57:26.427 [info] OAuth tokens saved
2026-04-15 12:57:26.428 [info] tokens() returning OAuth tokens
2026-04-15 12:57:27.014 [error] Auth-related error connecting to streamableHttp server: Streamable HTTP error: Server returned 401 after successful authentication Streamable HTTP error: Server returned 401 after successful authentication
2026-04-15 12:57:27.017 [info] tokens() returning OAuth tokens
2026-04-15 12:57:27.017 [info] MCP OAuth needsAuth (v2)
2026-04-15 12:57:27.018 [info] ReloadClient completed, connected: false, statusType: needsAuth
8

Sorry for my inappropriate language, cause I’m really not good at English

9

Hey @Connor_Chen1, your English is totally fine, no worries. And thanks for the logs, they’re helpful. It looks like the token exchange and refresh both succeed, and the 401 happens only on the follow-up request to the streamableHttp server. This is another variant of the same MCP OAuth issue we’re tracking.

Can you try a couple things:

  1. Remove the Postman MCP plugin, restart Cursor, log out of Postman in the browser at web.postman.co, then install the plugin again and go through auth. A clean Postman session sometimes helps.
  2. Try keeping only one Cursor window open during the auth flow. Multi-window can sometimes break the callback.
  3. If you still get a 401 after reinstalling, it’s most likely on the Postman MCP server side. The token gets issued, but the server doesn’t accept it for the streamable request. In that case, it’s worth contacting Postman support too.

We know about the bug on our side in the auth flow, but we don’t have an ETA for a fix yet. If the steps above don’t fix it, please share the Request ID from the chat right upper corner > Copy Request ID and confirm that the 401 reproduces consistently.

16

Hey, quick update on the thread. The fix for the MCP OAuth flow on our side is merged and will ship in the next major release v3.3. The current stable v3.2.x does not include the fix yet.

Once v3.3 rolls out, please update, reinstall the Postman plugin, and try auth again. It also helps to do this with only one Cursor window open.

@Connor_Chen1 your case is a bit different. The token exchange works, but the streamableHttp request returns 401. Our fix may address part of this, but if you still see 401 after updating to v3.3, it is most likely on the Postman MCP server side, so please also contact their support.

If the issue still reproduces after updating, please share the Request ID chat in the top right > Copy Request ID and the latest output from View > Output > MCP, and we will take a look.