Linear MCP OAuth on WSL2: Invalid client while IDE auth works

Where does the bug appear (feature/product)?

Cursor CLI

Describe the Bug

Connecting Linear MCP from WSL2 / Cursor agent fails at Linear authorize with: Invalid client. The clientId provided does not match to this client. The same Linear MCP plugin authenticates successfully in the Windows Cursor IDE. Linear asked us to file this with Cursor support because they do not control the client IDs Cursor sends.

Steps to Reproduce

  1. Install Linear MCP in Cursor on Windows. Connect from Settings > MCP. Auth succeeds in the IDE.
  2. Open the same workspace through WSL2. Linear MCP shows needsAuth.
  3. Start Connect / OAuth from the WSL side.
  4. Browser shows Invalid client. The clientId provided does not match to this client.

Expected Behavior

WSL/agent OAuth should complete against mcp.linear.app, or Cursor should drop the stale DCR client_id and register a fresh one. A working Windows IDE Linear session should not be required for the WSL agent.

Operating System

Windows 10/11

Version Information

Cursor 3.8.11 commit e56ad3440df06d22ca7501e65fd518e905486ef0 on Windows 11 + WSL2 Ubuntu x64. WSL networking is default NAT, not mirrored.

Additional Information

WSL stores a DCR client_id in mcp-auth.json with no tokens and retries that dead id. Linear GitHub issue: MCP OAuth on WSL2: Invalid client. The clientId provided does not match to this client (Cursor IDE works) · Issue #1273 · linear/linear · GitHub

Does this stop you from using Cursor

No - Cursor works, but with this issue

Hey @wqsaali_official, thanks for the detailed report, and for the Linear issue link!

What you found matches what we see on our side: the CLI in WSL keeps the OAuth client it registered with Linear in ~/.cursor/projects/<project>/mcp-auth.json and reuses it on every Login. If Linear no longer accepts that registration, the error only shows up on Linear’s page and the CLI has no way to notice it or start over, so retrying keeps hitting the same wall. The Windows IDE registers its own client with a different callback, which is why it keeps working and why its session does not carry over to WSL.

Could you try a clean re-registration so we can confirm which side is blocking? Please follow these steps exactly:

  1. In WSL, quit every running agent / cursor-agent session (including any /mcp screen).
  2. Run ls ~/.cursor/projects/*/mcp-auth.json and open the file for the project you are working in.
  3. Delete the Linear entry from that JSON (the top-level key for your Linear server, for example "linear": { ... }), then save. If Linear is the only server in the file, you can delete the whole file instead.
  4. Close the Cursor app on Windows for this test, so nothing on the Windows side is listening on port 8787 while WSL needs the callback.
  5. From your project folder in WSL, run agent mcp login <your Linear server name> (or start agent, open /mcp, select Linear, choose Login) and open the URL it prints in your Windows browser.
  6. Tell us what Linear shows: (a) the normal Linear consent screen, or (b) “Invalid client” again straight away. If (a), please also say whether the browser then lands on localhost:8787/callback and the CLI reports the server as ready.

If you want to keep working in the meantime, Linear’s MCP also accepts a personal API key: in WSL, add "headers": { "Authorization": "Bearer <your Linear API key>" } to the Linear entry in ~/.cursor/mcp.json (a Read-only key works for read use cases). That skips the browser flow entirely.

I followed the same steps and now Linear is showing the normal Linear consent screen and on sucess it is handling callback properly so i got access to Linear MCP within wsl2.

Looks like its fixed for me. Thanks