Feature request: Support user-invocable-only canvases
- Dominant language
- No language data
- Stars
- 2.1k
- Forks
- 153
- PR merge metrics
- No merged PRs in 30d
Description
### Summary
Add a canvas visibility/invocation setting that allows extension authors to expose a canvas to users without making it discoverable or invocable by the agent.
### Problem
User-scoped canvases are registered with every applicable session. Their declarations become available to the agent, which:
- Allows the agent to open the canvas without an explicit user request.
- Adds canvas metadata to the model's input context.
- Prevents authors from building strictly user-initiated utilities.
- Creates unnecessary token overhead for canvases that are rarely used.
Omitting `actions` prevents action invocation but does not prevent agent discovery or opening.
### Proposed API
```js
createCanvas({
id: "example",
displayName: "Example",
description: "An explicitly opened utility.",
invocation: {
user: true,
agent: false,
},
open: async (context) => {
// ...
},
});
```
A simpler alternative:
```js
agentInvocable: false
```
### Expected behavior
When `agentInvocable` is `false`:
- The canvas remains visible in user-facing canvas discovery and commands.
- Users can open it explicitly.
- Its declaration and action schemas are excluded from model context.
- `open_canvas` and `invoke_canvas_action` cannot target it.
- Canvas-internal, app-only tools continue to work.
- The default remains agent-invocable for backward compatibility.
### Acceptance criteria
- Extension authors can independently configure user and agent invocation.
- User-only canvases consume no model-context tokens before explicit use.
- Agent attempts to invoke user-only canvases fail with a clear authorization error.
- Invocation restrictions are enforced by the host, not only through instructions.
- The setting works for user-, project-, and session-scoped extensions.
- Existing canvas extensions retain their current behavior.
### Motivation
This would enable dashboards, editors, configuration panels, and other interactive utilities that should be available on demand without permanently expanding every agent session's tool surface.
Contributor guide
Research direction
The issue names createCanvas, open_canvas, and invoke_canvas_action but no files or tests. Start by locating those entry points and tracing how canvas declarations reach model context and how host invocation is authorized. Done means user-only canvases remain user-discoverable, are excluded from model context, reject agent calls clearly, and preserve existing defaults.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- javascript
- Domain
- api
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100