Cursor rewrites localhost URLs on WSL instead of opening the original port

Support Bug Reports
, ,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

When using Cursor with a WSL2 workspace on Windows, ctrl-clicking a http://localhost: link such as http://localhost:3000 opens a different forwarded port like localhost:3001 or a random high port instead of opening the original URL.

This happens even though the service is already reachable from Windows at localhost:3000 via WSL’s built-in localhost loopback. It also happens even when auto port forwarding is disabled.

Steps to Reproduce

Open a WSL2 workspace in Cursor on Windows.
Start a dev server inside WSL on port 3000, for example next dev.
Verify in a Windows browser that typing http://localhost:3000 works.
In Cursor, ctrl-click the http://localhost:3000 link shown in terminal output or a file.

Expected Behavior

Cursor should open exactly http://localhost:3000 in the system browser without rewriting the port.

Since WSL2 already exposes Linux services on localhost, no port forwarding should be required.

Screenshots / Screen Recordings

Screenshot 2026-02-07 002951.png
Screenshot 2026-02-07 002951.png1652×378 39.8 KB

Operating System

Windows 10/11

Version Information

Version: 2.4.30 (user setup)
VSCode Version: 1.105.1
Commit: 0f8217a84adf66daf250228a3ebf0da631d3c9b0
Date: 2026-02-06T23:20:57.191Z
Build Type: Stable
Release Track: Early Access
Electron: 39.2.7
Chromium: 142.0.7444.235
Node.js: 22.21.1
V8: 14.2.231.21-electron.0
OS: Windows_NT x64 10.0.26200

Additional Information

On WSL2, Linux services bound to port 3000 are already reachable at Windows localhost:3000. The Windows kernel reserves this port for WSL loopback, so Windows applications cannot bind it.

Cursor still attempts to forward the port and rewrites the URL, which is unnecessary and leads to confusion and broken expectations. Manually opening localhost:3000 in the browser works correctly. Only Cursor’s link handling causes the issue.

This appears to be a forwarding policy problem specific to WSL, not a networking limitation.

Does this stop you from using Cursor

No - Cursor works, but with this issue

4

Hey, thanks for the detailed report.

The screenshot confirms the issue: port 3000 is being forwarded to localhost:49773 instead of staying on :3000. This shouldn’t happen on WSL2, since ports are already available via localhost.

Workaround:

  1. In the Ports panel, remove all those forwards (right-click > Stop Forwarding)
  2. Add this to your settings.json:
    "remote.autoForwardPorts": false
  3. Restart Cursor

This should stop automatic port forwarding. If after this Ctrl-click still opens the wrong port, let me know. That would confirm a bug we need to escalate.

5

Yes, I tried turning automatic port forwarding off and then I restarted cursor. However, it still sent me to a different port when I ctrl+clicked.

6

Got it, this is a bug. Port 3000 is being forwarded to 49773 even though remote.autoForwardPorts: false should prevent that.

I’ve passed this to the team, thanks.

10

@deanrie bumping this bc the issue still persists.

here is my current config:

{

    "remote.autoForwardPorts": false,

    "remote.autoForwardPortsSource": "output",

    "remote.localPortHost": "localhost",

    "remote.restoreForwardedPorts": false,

    "remote.portsAttributes": {

      "3000": { "onAutoForward": "ignore" },

      "3001": { "onAutoForward": "ignore" }

    }

  }

Have noticed this issue since at least November 2025. Getting a bit arduous to type localhost:3000 every time.

Has caused major headache related to auth bug false flags due to mismatch between NEXT_AUTH_URL pointing to localhost:3000 to when server is running on localhost:3000.

Should be a straightforward fix. Can you escalate to engineering team? Thanks!

11

Hey, the bug is still on our radar. I see that the remote.autoForwardPorts: false + portsAttributes config isn’t helping, which is expected because the issue isn’t auto-forwarding. It’s about how Cursor rewrites the URL on Ctrl-click.

I’ve escalated this to the team. I can’t promise any specific timelines.

Can you also share the Cursor version you’re on right now? It’ll help for the report.

12

Its an issue on the most recent update that I installed on 03/03/26. I cannot find the version number. However like I said I have noticed this issue since at least November 2025 so its a recurring issue across many versions.

14

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

When using Cursor with a WSL2 workspace on Windows, ctrl-clicking a http://localhost: link such as http://localhost:4200 opens a different forwarded port like localhost:4201 or a random high port instead of opening the original URL.

This happens even though the service is already reachable from Windows at localhost:4200 via WSL’s built-in localhost loopback. It also happens even when auto port forwarding is disabled.

Steps to Reproduce

Open a WSL2 workspace in Cursor on Windows.
Start a dev server inside WSL on port 4200, for example next dev.
Verify in a Windows browser that typing http://localhost:3000 works.
In Cursor, ctrl-click the http://localhost:4201 link shown in terminal output or a file.

Expected Behavior

Cursor should open exactly http://localhost:4200 in the system browser without rewriting the port.

Since WSL2 already exposes Linux services on localhost, no port forwarding should be required.

Operating System

Windows 10/11

Version Information

Version: 3.0.12 (user setup)
VSCode Version: 1.105.1
Commit: a80ff7dfcaa45d7750f6e30be457261379c29b00
Date: 2026-04-04T00:13:18.452Z
Layout: editor
Build Type: Stable
Release Track: Default
Electron: 39.8.1
Chromium: 142.0.7444.265
Node.js: 22.22.1
V8: 14.2.231.22-electron.0
OS: Windows_NT x64 10.0.26200

Additional Information

This is the same bug report than Cursor rewrites localhost URLs on WSL instead of opening the original port

It started happening on latest cursor version.

Does this stop you from using Cursor

No - Cursor works, but with this issue

16

Do note that this bug also prevents all TUI authentication to external services (i.e. wrangler) through terminal panel as the loopback address is already in use or does not correspond to the port where the app is running.

Not blocking but very annoying…