Cursor 1.2.3 / 1.2.4 forwards a published port to the wrong container in Dev-Container workspaces

[pradelgorithm]

Describe the Bug

When a Docker-Compose-based Dev-Container workspace exposes port 3002 from a reverse-proxy container, Cursor 1.2.3 and 1.2.4 auto-forward that port to a different container (the main application container) that merely opens the same port internally.

The auto-forwarded entry shows the application process, not the proxy.

Requests therefore hit the wrong service (Express, Vite, etc.) instead of the proxy / downstream service.

forwardPorts, portsAttributes, and onAutoForward:“ignore” in devcontainer.json are ignored.

Cursor 1.2.2 (and VS Code) forward the port correctly.

Steps to Reproduce

Open any Dev-Container workspace that uses Docker Compose with two services:

reverse-proxy – publishes 3002 to the host (“3002:3002”).

app – runs dev server internally on 3002 but does not publish it.

Include in devcontainer.json:

“forwardPorts”: [3002],
“portsAttributes”: { “3002”: { “onAutoForward”: “ignore” } },
“otherPortsAction”: “ignore”

Open the folder in Cursor 1.2.4 (or 1.2.3) and let it build.

Observe the Ports panel:

Port 3002 is auto-forwarded to the app container instead of the reverse-proxy container.

Downgrade Cursor to 1.2.2, reopen the same workspace → port 3002 now maps to the reverse-proxy container as expected.

Expected Behavior

Cursor should forward the published host port (3002) to the container that actually publishes it (reverse-proxy).
User overrides (forwardPorts, portsAttributes) must take precedence over auto-detection.

Operating System

MacOS

Current Cursor Version (Menu → About Cursor → Copy)

MacBook Pro
14-inch, Nov 2024

Chip: Apple M4 Pro
Memory: 24 GB
Startup disk: Macintosh HD
macOS: Sequoia 15.5

Additional Information

Docker Desktop 4.41 (also happens with Podman 5.0)

Docker-Compose v2.35.1

Dev-Container Spec v1.0.0-rc.3

Removing /var/run/docker.sock, changing internal port, or editing portsAttributes does not change behaviour in 1.2.4

The issue appears to be a regression in Cursor’s auto-port-detection logic introduced after 1.2.2

Does this stop you from using Cursor

Yes - Cursor is unusable

[ravirahman]

Hi @pradelgorithm , thank you for this bug report. Could you confirm which dev container extension version you are on? We added support for portsAttributes and otherPortsAttributes in version 1.0.16 of the Anysphere Remote Containers extension. This is independent of the Cursor version.

[pradelgorithm]

@ravirahman im using 1.0.18, this is likely due to the extension rather than cursor, I had to open the dev container in vs code, then attach that container to the cursor rather than building it from cursor for it to work.

[ravirahman]

Thanks for confirming; we are looking into this issue.

[ravirahman]

Hi @pradelgorithm, could you upgrade to the latest version of the Dev Containers extension? In version 1.0.23, we reimplemented the “portsAttributes” and “otherPortsAttributes”, which should fix an issue where "otherPortsAction": "ignore" didn’t have any effect and could have resulted in this incorrect forwarding behavior.

[pradelgorithm]

I have re-tested this using Cursor 1.2.4 with a port labeled as reverse-proxy:3002, and the issue appears to be resolved.

The logs confirm that the forwarding is now correctly targeting the intended container:

2025-07-29 16:33:29.529 [info] Forwarding reverse-proxy:3002 to localhost:3002 for container ...

The port mapping behavior now aligns with the expected configuration defined in the devcontainer settings. Thank you for addressing this.