github / github/app

Show project/repo extension canvases in the 'Start a session from canvas' picker

Aperta
#2,634 0 commenti 1 reazione 0 assegnatari Vedi su GitHub
Lingua principale
Nessun dato sulla lingua
Stelle
2.1k
Fork
153
Metriche di merge delle PR
Nessuna PR unita negli ultimi 30g

Descrizione

### 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.

Guida per i contributori

Apri la guida per i contributori

Direzione di ricerca

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.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Valutazione

Ambito
desktop
Tipo di issue
Funzionalità
Difficoltà
5/5
Tempo stimato
Più di una settimana
Stato di attività
Tranquilla
Chiarezza
Abbastanza chiara
Idoneità per principianti
45/100

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.