Show project/repo extension canvases in the 'Start a session from canvas' picker
- Vorherrschende Sprache
- Keine Sprachdaten
- Sterne
- 2.1k
- Forks
- 153
- PR-Merge-Kennzahlen
- Keine gemergten PRs in 30 T.
Beschreibung
### Feature summary
Let project/repo extension canvases (`.github/extensions//`) appear in the "Start a session from canvas" picker, so a project-defined canvas can bootstrap its own session on a fresh machine.
### What problem are you trying to solve?
I build project-scoped canvas extensions (via `joinSession({ canvases: [...] })`) that act as control dashboards for a multi-session workflow. Each dashboard is meant to run in a dedicated, long-lived session that it "binds" to.
On a brand-new machine there is no such session yet, so I need a way to create the backing session directly from the canvas. The "Start a session from canvas" picker looked like exactly the right entry point, but it only lists standalone **host/plugin** canvases (e.g. Agency MCP Settings, Ask Bluebird, Azure DevOps). My **project** extension canvases never show up there, even though they load fine and open normally once a session exists.
Net effect: there's no first-run/bootstrap path for a project canvas. Today I have to ask the agent in some other session to `create_session` for me, which defeats the point of shipping a self-contained canvas with the repo.
### Proposed solution
- Include project- and user-scoped extension canvases in the "Start a session from canvas" picker (not just host/plugin canvases).
- When chosen, create a new session in the relevant project and immediately open that canvas in it (equivalent to `create_session` + `open_canvas`).
- For canvases that need an input (e.g. a session id), either prompt for it in the picker or allow the canvas to declare that it can open with empty/default input for the bootstrap case.
### Workflow impact
Enables a true first-run experience: clone the repo, open the project, pick the canvas, and it spins up its own dedicated control session — no manual agent step required. This is the missing piece for shipping canvas-driven, multi-session tools that are portable across machines.
### Installation context
GitHub Copilot desktop app on Windows. Project (repo-committed) canvas extensions under `.github/extensions/`.
### Additional context
Observed while building two project control canvases (`cr-twin-control`, `developer-repo-control`). `extensions_reload` labels them `[project]` and they're absent from the picker, while `[plugin]` canvases are present. `canvas.d.ts` in the shipped SDK has no session-template/bootstrap concept, which is consistent with the picker being host/plugin-only today.
Related but distinct: #2158 (plugin-provided canvases unavailable in general chat sessions) is about *opening* an already-registered canvas outside a project; this request is about *listing* project/user canvases in the "Start a session from canvas" picker so they can create their own backing session.
Beitragsleitfaden
Rechercherichtung
Start with the shipped SDK's canvas.d.ts and the extensions_reload behavior for [project] canvases, then trace the "Start a session from canvas" picker and the create_session/open_canvas entry points. Done means project- and user-scoped canvases appear in the picker, selection creates the relevant session and opens the canvas, and the input or empty/default bootstrap behavior is defined.
Vom Indexierungsmodell aus dem Issue-Text verfasst.
Bewertung
- Bereich
- desktop
- Issue-Typ
- Feature
- Schwierigkeit
- 5/5
- Geschätzter Aufwand
- Über eine Woche
- Aktivitätsstatus
- Ruhig
- Klarheit
- Größtenteils klar
- Anfängerfreundlichkeit
- 45/100