[Feature Request] Intercepting hardcoded localhost WebSockets for HMR (.NET Hot Reload / dotnet watch)

[akhanalcs]

What is your suggestion?

Implement a client-side interceptor or dynamic proxy mechanism within code-server's browser context that can catch outbound WebSocket requests to localhost:<port> and seamlessly route them through code-server's built-in proxy layer back to the remote workspace.

Why do you want this feature?

Developers relying on code-server for a pure browser-based development experience cannot use .NET's Hot Reload (dotnet watch).

When running dotnet watch, the .NET SDK dynamically injects a script (aspnetcore-browser-refresh.js) into the DOM that attempts to establish an HMR WebSocket connection to a random, ephemeral port on localhost (e.g., ws://localhost:40777).

Because the browser executes this locally, it queries the user's physical machine rather than the remote code-server container. The connection drops, and Hot Reload fails:
Firefox can’t establish a connection to the server at ws://localhost:40777/

Firefox can’t establish a connection to the server at ws://localhost:43067/.     aspnetcore-browser-refresh.js:318:25
WebSocket failed to connect.     aspnetcore-browser-refresh.js:19:15
Firefox can’t establish a connection to the server at wss://localhost:33935/.     aspnetcore-browser-refresh.js:318:25
WebSocket failed to connect.     aspnetcore-browser-refresh.js:19:15
Unable to establish a connection to the browser refresh server.     aspnetcore-browser-refresh.js:23:13

Are there any workarounds to get this functionality today?

There are no workarounds for a pure browser workflow (e.g., coding on an iPad or a locked-down laptop without CLI access).

Are you interested in submitting a PR for this?

No, I do not have the familiarity with the code-server networking/proxy codebase to implement this reliably.

[linear-code]

CODE-42

[code-asher]

Maybe something could be done with service workers but it feels sketchy to me because we would have to inject our own script into the proxied application.

I am also not sure service workers actually can intercept web sockets.

Ideally dotnet watch itself would support setting a target domain. Have you tried DOTNET_WATCH_AUTO_RELOAD_WS_HOSTNAME? But it might require a sub-domain proxy unless it lets you set a path.

Apparently there is also DOTNET_WATCH_AUTO_RELOAD_WS_PORT but is only in the 11 preview.

https://learn.microsoft.com/en-us/dotnet/core/tools/dotnet-watch#environment-variables