Project-scoped extension canvases are declared but not routable by open_canvas

[sull364]

Summary

Project-scoped extensions loaded from .github/extensions/ can initialize and register a canvas with createCanvas() + joinSession(), and the canvas appears to be declared in the runtime/system prompt. However, the canvas is not added to the runtime routing table: open_canvas cannot open it and list_canvas_capabilities does not find it.

The same canvas code works when installed as a user-scoped extension under ~/.copilot/extensions/.

Version

• Copilot CLI: 1.0.69
• Runtime: 1.0.66-1
• OS: Windows 11 (x64)

Repro

1. Create a project-scoped extension under .github/extensions/<extension-name>/extension.mjs.
2. Register a canvas using createCanvas().
3. Start the extension session with joinSession({ canvases: [canvas] }).
4. In Copilot CLI, ask to open that canvas or call open_canvas for the canvas ID.
5. Call list_canvas_capabilities for the same canvas ID/name.

Note: Extension logs confirm full initialization — joinSession completes, the catalog loads, and the HTTP server responds to requests. The extension process is healthy; only the runtime routing is broken.

Expected behavior

Project-scoped canvases registered through joinSession({ canvases: [...] }) should be added to the runtime canvas routing table and should be openable by open_canvas.

Actual behavior

• The extension initializes successfully.
• The canvas appears to be declared to the model/runtime.
• open_canvas fails with connection closed.
• list_canvas_capabilities returns No canvas matches.

Workaround

Opening the extension's local HTTP URL directly in a browser canvas works. Installing the same extension as a user-scoped extension under ~/.copilot/extensions/ also works.

Impact

Project-scoped Canvas extensions can be discovered/declared but cannot be opened, which blocks repo-local Canvas experiences from working without a user-scoped install or manual browser workaround.