Integrated Browser inside DevContainer should use the host port

[danmcpherson]

When using a DevContainer for development, local ports are mapped to random host ports.

When the agent calls the integrated browser it uses the local port which fails as the integrated browser is running in the context of the host.

So, the integrated browser should know the session is a DevContainer and open the mapped host ports rather than the inaccessible local container port.

[YKDZ]

I want to expand on why this is more critical than it might appear — specifically for autonomous AI coding agents operating inside devcontainers.

The root problem is deeper than browser URL resolution.

There is currently no programmatic way for any process inside a devcontainer to discover the container→host port mapping. We exhaustively investigated:

• ss -tnp on the container side shows which ports VS Code server is actively proxying, but not the external mapping
• VSCODE_IPC_HOOK_CLI only supports open, openExternal, status, extensionManagement — no port query exists
• The VS Code server HTTP API (port 33969) has no /ports or tunnel-state endpoint
• The SSH host has no TCP listeners for forwarded ports — forwarding is pure user-space WebSocket tunneling that terminates on the client machine, not the SSH host
• code --status window titles can expose the external URL only when a Browser Preview tab is actively open — not reliably queryable from agent code

Why this blocks agentic loops:

Autonomous agents run iterative build→verify→fix cycles. For web/UI work, "verify" means navigating to the running app. Without the correct external URL, the agent either navigates to the inaccessible container-internal port, or cannot verify at all — requiring human intervention to supply the URL. This defeats the purpose of autonomous operation.

Fix proposal:

A file written into the container by VS Code and kept up-to-date at runtime, e.g. /run/vscode-port-forwards.json:

{ "5176": "http://127.0.0.1:5177", "4174": "http://127.0.0.1:4174" }

Unlike environment variables (which are fixed at process start and cannot reflect runtime port fallback), a file can be written or updated by VS Code at any point — including after the local-side port fallback resolves. Any process inside the container can poll or watch it. The vscode.env.asExternalUri() API already computes these values; they just need to be written somewhere readable from inside the container.

Alternatively, a new listForwardedPorts message type on VSCODE_IPC_HOOK_CLI would achieve the same result via an IPC query.

[pl4nty]

local ports are mapped to random host ports

is this controlled by a setting? my devcontainer ports are forwarded to the matching Windows host port, or incrementing if it's unavailable, eg 3000 -> 3001. this works well with agents