Codespaces: forwarded ports (3000/3001) stay 502 after a container Rebuild — server-side relay keeps a stale mapping; only manual remove+re-add clears it

Summary

After Rebuild Container in a Codespace, ports that were forwarded in the previous container come back present but dead: the browser gets ERR_EMPTY_RESPONSE and a direct curl of the *.app.github.dev forwarded URL returns 502 Bad Gateway, even though a healthy listener is bound inside the container. The only recovery is manually removing and re-adding the port in the Ports panel.

Environment

• GitHub Codespaces, dev container via docker-compose (docker-outside-of-docker). App services run in sibling containers; the dev container re-exposes them on 0.0.0.0:3000/3001 via socat listeners.
• Reproduced across multiple rebuilds.

Repro

1. Forward a port (e.g. 3000) that a listener in the dev container serves; confirm it works in the browser.
2. Rebuild Container.
3. After rebuild, a fresh listener is bound on the same port (verified: curl localhost:3000 inside the container → 200).
4. Hit the forwarded https://<codespace>-3000.app.github.dev/ URL → 502; browser → ERR_EMPTY_RESPONSE.

Evidence the local side is healthy

What does NOT fix it (all tried in-container)

• Killing + re-listening the socat listener (a close→listen edge). gh codespace ports shows the port still registered for 100s+ after the listener dies — the server-side registration never deregisters.
• remote.restoreForwardedPorts: false (verified applied in the remote Machine/settings.json) — no effect on the 502.
• Listing the ports in forwardPorts with onAutoForward: "silent" (agent-owned forwarding, no in-container nudging) — same 502.

Only working recovery

Manual remove + re-add in the Ports panel (which calls the tunnel service delete/create). This path is not exposed by gh codespace ports (only forward/visibility), so it can't be scripted from a lifecycle command.

Ask

On rebuild, the tunnel relay should drop registrations tied to the destroyed container (or re-bind them to the new listener on the same port) rather than serving a 502 into the old container. Alternatively, expose a supported way (CLI/API) to force-refresh a port registration so it can be automated in a postAttach/postCreate hook.