Canvas on a Node
Render interactive Canvas content directly on a paired desktop node screen.
Canvas usually renders in the Dashboard panel next to the chat. But sometimes you want the artifact on a real screen: a chart on the meeting-room display, a dashboard on a wall-mounted PC, an SVG diagram on the machine sitting next to you. Sophon can open the live Canvas for the current session directly on a paired Sophon Node desktop.
This is part of the desktop node feature set. The agent pushes Canvas content as usual, then asks a Node to display it on its own screen.
How it works
The agent-facing tool is node.present_canvas. It takes one optional parameter:
| Param | Type | Notes |
|---|---|---|
node_id | string | Target Node. Optional, and defaults to the active Node. |
Under the hood the tool dispatches a canvas.present command to the Node, passing the current session id. The Node builds the Dashboard Canvas URL for that session, {gatewayUrl}/canvas?session={id}, and opens it in the machine's default browser. Because the browser reuses the user's existing Dashboard login, the Canvas renders and stays interactive with no token in the URL.
From that point on, everything the agent pushes via canvas.render, including new frames, updated frames and interactive components, streams live onto the Node's screen over SignalR, exactly as it would in the Dashboard panel.
node.present_canvas({ node_id: "meeting-room-pc" })Call it after you have pushed Canvas content, so there is something to show when the page opens.
What it's good for
- Charts and dashboards on a remote screen. Render an agent-built dashboard on a display across the room or across the building.
- Visuals during a demo or meeting. Open the Canvas on the presenting machine so the audience sees the artifact, not your chat window.
- Diagrams and prototypes on a second machine. Push a Mermaid diagram or an HTML prototype to the screen sitting next to you while you keep the chat on your laptop.
Permission scope
The Node must hold the canvas.control scope, which is one of the eight a device is granted when you approve it. In the Dashboard it lives under Devices → (device) → Settings → Permission scopes. Remove it and the Gateway rejects the command before it ever reaches the Node. See Permissions & Scopes for how scopes are granted and audited.
canvas.present is consent-gated on the Node by default, so a remote machine cannot silently pop up pages without the local user's awareness. See the on-device consent prompt for how that prompt behaves and how to change which commands raise one.
Two separate approvals
Presenting a Canvas on someone's screen passes two checks that do not know about each other.
In the conversation. node.present_canvas is a Medium-risk tool, and at the shipped default threshold that raises an approval. It is raised once, before the command runs, and it goes to the channel the conversation is actually happening in rather than only to a Dashboard nobody is looking at.
Because presenting counts as driving that machine, approving it in an interactive chat turn can also cover further desktop actions at that risk level on that machine for the rest of the run. That standing consent lasts thirty minutes, belongs to one conversation, is held in memory so a Gateway restart clears it, and never covers Critical. A workflow, a scheduled or cron run, a heartbeat turn, a webhook turn and an MCP call are never covered and ask every single time. See plan-level consent.
On the machine. The node then raises its own prompt on the screen the Canvas is about to open on. That one is not affected by anything approved in chat: it is asked per command, every time, times out after 15 seconds, and fails closed. A node with no interactive desktop session cannot show it, and so cannot present at all.
The command behind it
The tool dispatches a canvas.present command to the node.
Scope: canvas.control · consent-gated on the device
| Param | Type | Default | Notes |
|---|---|---|---|
sessionId | string | required* | Session whose Canvas to show. *Unless url is given |
url | string | none | Explicit URL override. Only http and https are accepted; anything else is refused |
canvas.present is one of the command types an agent cannot put in a Control Run. It is reachable only through node.present_canvas.
Relationship to Remote Control
node.present_canvas is a sibling of the broader Remote Control capability, but it serves a different purpose:
- Remote Control drives the desktop: screen capture, mouse, keyboard, app and window management. It is about operating the machine, and its mechanics are in Control Runs.
- Canvas on a Node is one-way output: it puts a rendered, interactive Canvas on the screen. The agent isn't clicking around the OS; it's handing a live artifact to a display.
The two compose well. You might use Remote Control to open the right app or arrange windows, then node.present_canvas to drop the agent's chart onto that same screen.
Notes
- The Node opens the Canvas in whatever browser is configured as the system default.
- The session must be active, and the tool reports an error if there is no session to present.
- The node needs a real desktop session to open a window in, which is one more reason it runs as a user-level service.
Where to go next
- Canvas — what Canvas is and how the agent populates it
- Control Runs — operating the desktop, rather than presenting to it
- Permissions & Scopes — granting the
canvas.controlscope - Commands & Actions — the full node command reference
Desktop Awareness
How an agent finds out what is on your screen and what you were working on, via the on-demand desktop context, the background activity recorder, and the desktop.activity tool.
Permissions & Scopes
The scopes a node can hold, which eight are granted by default, and how to change or revoke them.