Dev container won't forwards port under 1024

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Dev Container port forwarding can’t forward ports lower then 1024 to the same port. Instead another random high port number is chosen.

When trying to forward a port under 1024 (eg port 80) inside a dev container, the port is always forwarded to a random high port number instead of the original port number.

This happens both when automatically forwarding a port and when manually forwarding it.
Having the port listed in devcontainer.json does not help

Port forwarding in the exact same dev container works fine in VSCode.
I am using the Anysphere dev container plugin (lastest version; v1.0.25)

This has worked correctly before, I am unsure which version caused this regression.

This problem causes issues where a correct port is expected instead of a random one every time the container is started.

Steps to Reproduce

  • Have a dev container that exposes a port under 1024 (eg port 80)
  • Start the container
  • Go to the ports tab
  • The low port number is now forwarded to a random high port number.

Alternatively:

  • Have a dev container that exposes a port under 1024 (eg port 80)
  • Start the container
  • Go to the ports tab
  • Remove all port forwards
  • Add a new port with the ‘Add Port’ button.
  • Chose a low port number
  • The low port number is now forwarded to a random high port number.

Expected Behavior

I expect all port numbers to be able to be forwarded correctly, not just ports above 1024.

Operating System

Windows 10/11

Current Cursor Version (Menu → About Cursor → Copy)

Version: 1.7.46 (user setup)
VSCode Version: 1.99.3
Commit: b9e5948c1ad20443a5cecba6b84a3c9b99d62580
Date: 2025-10-14T01:21:46.830Z
Electron: 34.5.8
Chromium: 132.0.6834.210
Node.js: 20.19.1
V8: 13.2.152.41-electron.0
OS: Windows_NT x64 10.0.26100

Does this stop you from using Cursor

No - Cursor works, but with this issue

We do not support forwarding ports < 1024 due to the need for elevated privileges for these ports.

What sparked this change and is there a timeline when this will be fixed?

VSCode can do this without issues
Cursor can also do this without issues when using the old microsoft dev containers extension
Cursor always used to be able to do this up untill a recent update.

I would say that being able to choose a sub-1024 port in a dev container is basic functionality and required for some applications to properly work.

Any update on this?
I am forced to use VSCode for our projects because of this regression, while I would rather be using cursor.

If I can’t use cursor for basic tasks, it’s not really worth keeping our subscription unfortunately.

Any update on this?

I’ve been running into multiple problems because of this regression already and having to make hacky workarounds, or even go back to VSCode to get things to work properly.

Hi @Elwin, we have fixed this for macOS hosts in version 1.0.27 of the Cursor Remote Containers extension.

If you are on Windows, are you running your container inside WSL?

  • If so, We do not support low-number port forwarding for Docker-over-WSL (e.g. the docker container was launched with a WSL shell), as the forwarder process (on the WSL side) would be bound by linux’s low-number port restrictions.

  • However, containers launched from the Windows side (e.g. docker run from a powershell console) should support low-number ports, as the forwarding process will run in Windows, which does not have such restrictions on port numbers.

I am running the dev container inside WSL2 on windows.

The exact same containers have no issues at all with sub-1024 ports in VSCode using the microsoft dev containers extension.

The exact same containers also have no issues at all with sub-1024 ports in cursor using the old microsoft dev containers extension (one of my cursor installs got stuck on the old MS extension).

So the limitation seems to stem from the Anyspehere dev containers extension, not an inherit WSL2 limitation.

Yes – this is a limitation in our WSL extension, as we rely on the default NAT mode to expose linux ports in windows.

As a workaround, I would recommend using a proxy like netsh. For example, after exposing the high-number port inside WSL, you can forward it to a low number port by running netsh in a powershell. Please see this video for an example.

This topic was automatically closed 22 days after the last reply. New replies are no longer allowed.