github / github/app

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

未关闭
#2,634 0 条评论 1 个 reaction 已指派 0 人 在 GitHub 查看
主要语言
没有语言数据
星标
2.1k
派生
153
PR 合并指标
30 天内没有已合并 PR

描述

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

贡献指南

打开贡献指南

调研方向

从随附 SDK 的 canvas.d.ts 和针对 [project] canvas 的 extensions_reload 行为开始,然后跟踪 "Start a session from canvas" picker 以及 create_session/open_canvas 入口点。完成标准是:项目范围和用户范围的 canvas 出现在 picker 中,选择后会创建相应的 session 并打开 canvas,并且输入或空/默认 bootstrap 行为已定义。

由索引模型根据 Issue 内容生成。

评估

领域
desktop
Issue 类型
功能
难度
5/5
预计耗时
一周以上
活跃度
冷清
描述清晰度
基本清楚
新手友好度
45/100

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。