feat: host-browser passthrough, xdg-open shim, and code bridge for idc shell/copilot

[rosstaco]

What

Piggyback on a connected VS Code session so idc shell and idc copilot reproduce VS Code's terminal host-bridges — without VS Code having to be the thing you launched. Same parasitic trick already used for SSH_AUTH_SOCK.

When a VS Code window is attached to the devcontainer, idc discovers its CLI IPC socket and browser helper inside the container (find_vscode_bridges, mirroring find_ssh_socket) and injects them on docker exec:

• Host-browser passthrough — sets BROWSER + VSCODE_IPC_HOOK_CLI, so browser logins (az login, gh auth login, glab auth login, snowflake, …) open your host browser, and the OAuth localhost callback completes via VS Code's automatic port forwarding. Applies to both idc shell and idc copilot.
• xdg-open shim — materializes an xdg-open (plus x-www-browser/gnome-open/gnome-www-browser/sensible-browser/www-browser aliases) ahead of PATH that execs the VS Code browser helper. This fixes tools that call xdg-open directly and ignore $BROWSER — which neither VS Code nor a plain $BROWSER export can forward. Applies to both subcommands.
• code bridge — idc shell prepends VS Code's remote-cli dir to PATH so code <file> opens in the connected window.

All of this needs VS Code connected; otherwise idc prints a one-line hint and continues unchanged (no behavior change, argv identical to today).

Why the xdg-open shim (the Atlassian acli case)

Verified by inspecting both the macOS and acli_linux_amd64 binaries: acli (Go) opens the browser via its own OpenBrowser util — open on macOS, bare xdg-open on Linux — with zero $BROWSER references and no fallback chain. VS Code only sets $BROWSER and never shims xdg-open, so acli works on a Mac host but silently no-ops in a VS Code dev container. Because it calls bare xdg-open (PATH-resolved), the shim intercepts it → host browser. This makes idc strictly better than a plain VS Code terminal here.

How it works (mechanism, verified against microsoft/vscode)

BROWSER=<server>/bin/helpers/browser-linux.sh just runs node out/server-cli.js --openExternal <url>, which talks over VSCODE_IPC_HOOK_CLI to the connected VS Code, which opens the host browser. Discovery is one combined docker exec sh -c probe returning the IPC socket, browser helper, and remote-cli dir (each test-validated).

Testing

• TestFindVscodeBridges (mirrors TestFindSshSocket) + env/PATH-wrapper injection assertions for both subcommands.
• The generated PATH wrapper was executed end-to-end with a real shell to prove xdg-open and an alias both forward to the helper.
• uv run ruff check clean; uv run pytest — 366 passed.

Out of scope / notes

• VS-Code-independent relay (host opener server + host.docker.internal + callback-port proxy) is documented as deferred in project/plans/2026-06-30-browser-passthrough/.
• copilot /copy: investigated separately. It uses an in-process native X11/Wayland clipboard (no shell-out, no $BROWSER), printing a scary Failed to create clipboard context: $DISPLAY variable not set in containers — but it falls back to OSC 52, which rides the -it PTY straight through docker exec and reaches the host clipboard. Confirmed working; it's an upstream cosmetic-error issue (/copy shows clipboard error but still copies successfully github/copilot-cli#3521), nothing for idc to change.

Docs: README.md updated; research + plan under project/plans/2026-06-30-browser-passthrough/.