The port is shown as forwarded in the ports tab, yet localhost:8100 cannot be reached (running in a workspace reached via ssh anysphere plugin, remote: linux, local: MacOS X).
On the other hand, it works in VS Code.
Expected Behavior
Port should be forwarded.
Operating System
MacOS
Version Information
Version: 3.7.36
Commit: 776d1f9d76df50a4e0aeca61819a88e7c1b861e0
Date: 2026-06-13T00:31:56.287Z
Layout: editor
Browser: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Cursor/3.7.36 Chrome/142.0.7444.265 Electron/39.8.1 Safari/537.36
Hey, thanks for the report. This looks like an IPv4 vs IPv6 mismatch when resolving localhost on macOS. In that case, the port can show as forwarded, but the local listener is actually bound to a different address.
Can you try these instead of localhost:8100:
http://127.0.0.1:8100
http://[::1]:8100
If one of them works but localhost:8100 doesn’t, that confirms it’s an IPv4 vs IPv6 bind issue. Let me know what you get and we can file an issue with the details.
Thanks, that’s an important detail, so it’s not an IPv4 vs IPv6 mismatch. The listener just isn’t coming up the way it should. The workaround via VS Code or direct SSH makes sense, but let’s collect a couple of things to debug it:
On your local Mac, while the port shows as forwarded in Cursor, run this in Terminal:
lsof -nP -iTCP:8100 | grep LISTEN
I’m curious if Cursor is actually listening on that port locally at all, and on which address.
How many Cursor windows are open when the issue happens? If it’s multiple, especially multiple remote windows, check if the port still forwards when the correct window is active and focused.
Remote SSH logs: open View > Output, then in the dropdown at the top right select the Remote - SSH channel or Anysphere Remote, and share whether there are any tunnel or forward errors around the time you start the server.
With that info, I can report an issue with solid details. Let me know what you find.
2) 1 Cursor window (the arc workspace). Reproduces alone and focused.
3) Real cause is in the tunnel-forwarding log — fires on every attempt:
[info] [tunnel-forwarding][localhost:8100 -> 0.0.0.0:8100] server listening
[info] Cross binding to [::1]:8100. Originally bound to 127.0.0.1:8100
[error] [tunnel-forwarding] no remote dialer available; arbitrary TCP forwarding is unavailable in socket mode
Doesn’t fix it:AllowTcpForwarding yes in sshd_config (already effective), rm -rf ~/.cursor-server + reconnect, binding the app to :: / 0.0.0.0 / 127.0.0.1, restarting Cursor.
Does work at the same moment on the same target:ssh -N -L 8100:localhost:8100 <host>, and VS Code Insiders’ Remote-SSH forward.
That error string — arbitrary TCP forwarding is unavailable in socket mode — should be a straight grep in the extension: looks like the socket-mode transport branch is missing the dialer that the WebSocket-mode branch has.
Hey, thanks for such a detailed diagnosis, that’s exactly what we needed.
Your log makes it clear this isn’t an IPv4/IPv6 mismatch, it’s exactly what tunnel-forwarding shows:
no remote dialer available; arbitrary TCP forwarding is unavailable in socket mode
So when the connection goes through socket mode, arbitrary TCP port forwarding doesn’t work the same way as in VS Code, which is why you get an instant RST even though the port shows as forwarded. This matches the original report on macOS too, so it’s not platform-specific.
Working workaround (you already found it, reposting for anyone who finds this thread):