Provider-initiated canvas.close removes runtime instance but leaves panel visible

Start by tracing the session.rpc.canvas.close({ instanceId }) path from the extension API into the desktop host's canvas panel state. Reproduce the provider-initiated close and verify that the matching panel is dismissed or that the request is rejected when unsupported; add a regression test if the relevant canvas behavior tests are available.

Description

When a canvas extension calls session.rpc.canvas.close({ instanceId }), the runtime removes the canvas instance, but the GitHub Copilot desktop app continues displaying the canvas panel.

The panel can still be closed manually. This is different from an iframe becoming stuck or its normal close control failing.

Steps to reproduce

1. Create an extension-backed canvas using createCanvas().

2. Open it using a known instanceId.

3. From the extension, call:

   await session.rpc.canvas.close({ instanceId });
   

4. Observe that the canvas remains visibly open in the desktop app.

5. Attempt to invoke an action against the same instance.

Actual behavior

The panel remains visible and interactive-looking, but the runtime reports that the canvas no longer exists:

Request session.canvas.action.invoke failed with message:
Canvas instance "interactive-demo-2" is not open.
No canvases are currently open.

The visible panel can still be closed manually by the user.

This produces a runtime/host state mismatch:

• Runtime: canvas is closed
• Desktop host: canvas panel remains visible
• Subsequent canvas actions: rejected because the instance is no longer open

The issue also occurs when the extension performs a human-in-the-loop handoff:

await session.send({ prompt: handoffPrompt });
await session.rpc.canvas.close({ instanceId });

The submitted prompt reaches the conversation successfully, and the close call does not throw, but the panel remains visible.

Expected behavior

After session.rpc.canvas.close({ instanceId }) completes, the desktop host should dismiss the corresponding canvas panel and emit/render the closed state consistently.

Alternatively, if provider-initiated closing is unsupported, the API should reject the request rather than removing the runtime instance while leaving the host panel visible.

Use case

A custom canvas is used as a human-in-the-loop form or editing interface. When the user clicks Submit, the extension:

1. Captures and sends the complete canvas state to Copilot.
2. Closes the now-unneeded canvas.
3. Lets Copilot continue processing in the conversation.

The handoff succeeds, but automatic panel dismissal does not.

Environment

• GitHub Copilot app: 1.0.87-0
• OS: macOS
• Canvas type: extension-owned iframe canvas
• Extension scope: session
• SDK API: session.rpc.canvas.close