Extension canvases never appear in side panel for WSL remote-host sessions

[oschingka]

Short summary

Extension canvases never appear in the side panel for sessions running on a WSL remote host

Affected version or release

Copilot CLI runtime 1.0.89-1 (linux-x64, running in WSL Ubuntu); GitHub Copilot app on Windows

Installation context

Windows desktop app, worktree-backed project session with execution_location: remote (remote_host_id: wsl:Ubuntu). WSL2 networkingMode=Mirrored. User-level canvas extension in ~/.copilot/extensions.

What happened?

Calling open_canvas for a user extension canvas succeeds, but nothing appears in the app side panel. The panel only shows the default launcher (Changes / Browser / Terminal / Files / Canvas) and no canvas tab is created.

Evidence that everything up to the app UI works:

• extensions_manage inspect reports the extension as running; the log reaches === ready === with no errors.
• open_canvas returns success with a url like http://127.0.0.1:<port>/?token=....
• session.canvas.recorded events are written to the session events.jsonl for each instance.
• The extension HTTP server responds (200) to the page, assets, and API from inside WSL.
• Opening the same URL in Windows Edge (headless) loads and renders the editor correctly, and the extension sees the client connect. Mirrored networking means Windows can reach the loopback port.
• The app side panel never requests the URL at all: the extension never sees a client connection from the panel (state stays connection: connecting, clientId: null).

Re-opening the same instanceId, opening a new instanceId, and restarting the app did not help.

Steps to reproduce

1. On Windows, create a project session that runs on a WSL remote host (wsl:Ubuntu).
2. Install a user canvas extension in WSL ~/.copilot/extensions/<name>/extension.mjs that registers a canvas via joinSession({ canvases: [...], requestCanvasRenderer: true }) and returns a loopback url from open.
3. Ask the agent to open the canvas (open_canvas).
4. Observe that the tool call succeeds, but the side panel shows no canvas.

Expected behavior

The canvas opens as a tab in the side panel and loads the extension URL, the same way it does for local (non-remote) sessions.

Additional context

• open_canvas result status is success; no session.canvas.unavailable is seen.
• Workaround: open the returned URL manually in a browser.
• Side panel after open_canvas shows only the empty launcher with "Canvas" listed.

[Chuxel]

Canvases are not yet available in WSL.

[oschingka]

Update: the workaround is confirmed to work.

Opening the URL returned by open_canvas in the app's built-in Browser tab loads the canvas page, and the extension sees the client connect. The agent can then drive the page through the extension's canvas actions on that instance (both read-only queries and UI actions), and the results show up live in the Browser tab.

So the extension, its loopback server, and the Windows-to-WSL networking all work. Only the side panel fails to create and load the canvas for the remote (WSL) session.

[oschingka]

Canvases are not yet available in WSL.

Would be an amazing feature to have