github / github/app

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

Ouverte
#2,634 0 commentaires 1 réaction 0 personnes assignées Voir sur GitHub
Langage dominant
Aucune donnée de langage
Étoiles
2.1k
Forks
153
Métriques de merge des PR
Aucune PR mergée en 30 j

Description

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

Guide de contribution

Ouvrir le guide de contribution

Piste de recherche

Commencez par le canvas.d.ts du SDK fourni et le comportement de extensions_reload pour les canvas [project], puis suivez le picker "Start a session from canvas" et les points d’entrée create_session/open_canvas. Le travail est terminé lorsque les canvas associés à un projet et à un utilisateur apparaissent dans le picker, que la sélection crée la session correspondante et ouvre le canvas, et que le comportement de bootstrap pour l’entrée ou pour une valeur vide/par défaut est défini.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Évaluation

Domaine
desktop
Type d'issue
Fonctionnalité
Difficulté
5/5
Temps estimé
Plus d'une semaine
Activité
Calme
Clarté
Plutôt claire
Accessibilité débutants
45/100

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.