github / github/app

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

Abierto
#2,634 0 comentarios 1 reacción 0 asignados Ver en GitHub
Lenguaje dominante
Sin datos de lenguaje
Estrellas
2.1k
Forks
153
Métricas de merge de PR
Sin PR fusionados en 30 d

Descripción

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

Guía de contribución

Abrir la guía de contribución

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Evaluación

Área
desktop
Tipo de issue
Nueva funcionalidad
Dificultad
5/5
Tiempo estimado
Más de una semana
Estado de actividad
Tranquilo
Claridad
Bastante claro
Aptitud para principiantes
45/100

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.