Project-level canvas extension discovery regressed between 1.0.87-0 and 1.0.90-0 (target_session_extensions always 0) #5057

Summary

A project-level canvas extension (.github/extensions/<name>/extension.mjs) that was manually verified working end-to-end stopped being discovered after the CLI app auto-updated. The host's own logs show it now computes zero target extensions for the project and never even attempts to scan/spawn the extension file — this is not an extension-side crash, it's a discovery regression.

Environment

• Windows, Copilot CLI app directory shows installed package versions: 1.0.83, 1.0.87-0, 1.0.90-0 under %LOCALAPPDATA%\copilot\pkg\win32-x64\.
• Extension last confirmed working under 1.0.87-0 (per project's own changelog, verified 2026-10-01).
• Currently running 1.0.90-0 (auto-updated); extension no longer loads.

Repro

1. Have a project with .github/extensions/<id>/extension.mjs that calls joinSession({ canvases: [createCanvas({ id: "<id>", ... })] }) at module load (top-level await), following the documented project-extension pattern.
2. Open/resume a project session for that repo.
3. Attempt open_canvas with that canvas id.

Expected

Canvas registers successfully (as it did under 1.0.87-0), and open_canvas succeeds.

Actual

open_canvas fails with:

Request session.canvas.open failed with message: No canvas "<id>" is registered.

This reproduces even after:

• A full app restart (confirmed via new ws.port/ws.token timestamps in %USERPROFILE%\.copilot\run\).
• Creating a brand-new session/workspace for the same project.
• Confirming extension.mjs has valid syntax (node --check passes) and is in the exact same location/format that worked previously.

Evidence from app logs (%USERPROFILE%\.copilot\logs\github-app.<pid>.log)

On session resume, only the three built-in canvases are declared — the project extension is absent from the start:

INFO ... session::core: Declaring canvases on session.resume count=3 ids=["editor", "browser", "terminal"]

The extensibility refresh immediately after reports the host's own target extension count as 0 for this session, despite a real project extension existing on disk:

INFO ... session::manager::mcp_status: extensibility live-session refresh completed session_id=... plugins_stale=false mcp_stale=false extensions_stale=true skills_stale=true extensions_reconciliation_needed=false extension_reconciliation_count=0 observed_session_plugins=0 target_session_plugins=0 observed_session_mcp=0 target_session_mcp=0 observed_session_extensions=None target_session_extensions=0 target_session_skills=0 duration_ms=79

The warm_canvas_catalog_backfill task runs a full probe cycle (creates a temp CLI session for the project cwd, waits ~8s, destroys it) but produces zero log lines mentioning the extension file path or its canvas id anywhere — i.e. discovery isn't failing to load the file, it isn't looking for it at all:

INFO ... canvas_catalog: probing canvas catalog cwd="<project path>"
INFO ... session::core: creating session session_id="<cli-generated>" cwd="<project path>" session_type=Project enable_config_discovery=true
INFO ... session::core: CLI session created cli_session_id=... create_session_rpc_ms=198 enable_config_discovery=true
... (8s gap, no extension/canvas mentions)
INFO ... session::core: destroying session session_id=...

Separately, under the previously-working 1.0.87-0, a per-extension bootstrap log (%USERPROFILE%\.copilot\logs\extensions\project-<id>-<timestamp>-<pid>.log) shows the full expected bootstrap sequence reaching === ready ===:

[extension-fork] resolveBootstrapPath: ...
[extension-bootstrap] starting: pid=..., COPILOT_SDK_PATH=..., EXTENSION_PATH=..., SESSION_ID=...
[extension-bootstrap] importing extension: <path>\extension.mjs
[extension-resolver] resolver hook loaded: pid=..., COPILOT_SDK_PATH=...
=== ready ===

Under 1.0.90-0, no such bootstrap log is produced at all for subsequent open attempts — confirming the extension process is never spawned post-update.

Impact

Any project relying on a .github/extensions/* canvas extension loses that UI entirely after updating to 1.0.90-0, with no error surfaced to the user beyond a generic "No canvas registered" message when they try to use it — the actual failure (discovery never running) is silent and only visible in internal debug logs.

Suggested investigation starting points

• Diff the project-extension discovery/scanning logic between 1.0.87-0 and 1.0.90-0 (whatever populates target_session_extensions in session::manager::mcp_status).
• Check whether warm_canvas_catalog_backfill / canvas_catalog probing changed its search path, file-matching glob, or an enablement condition for .github/extensions.
• Consider surfacing a discovery failure (vs. silent 0-extensions) to make this class of regression visible without log spelunking.