mirror of
https://github.com/openclaw/openclaw.git
synced 2026-07-15 06:26:04 +00:00
0af8467137
* feat(dashboard): modular dashboard — workspace store, Workspaces tab, sandboxed custom widgets Squashes openclaw/openclaw#101094 + #101097 + #101098 onto current main and applies the maintainer review fixes to the backend control plane. Co-authored-by: 100yenadmin <239388517+100yenadmin@users.noreply.github.com> * fix(dashboard): UI review fixes — grid, error boundary, embed sandbox, locale * fix(dashboard): make the CLI and agent broadcasts actually reachable Three defects only a live run surfaces, all invisible to the unit suites: - The plugin claimed the CLI command name `dashboard`, which core already owns (it opens the Control UI). A plugin CLI group that overlaps a core command is dropped at registration behind a `logger.debug`, so the entire CLI face was unreachable while `cli.test.ts` kept passing against its own Commander program. Renamed to `openclaw workspaces`, matching the tab it drives. - The manifest never declared `activation.onCommands`, so the CLI root resolved to no owning plugin even once the name was free. - `dashboard.widget.approve` needs `operator.approvals`; the CLI asked for `operator.write` on every call. It now requests the approvals scope only for the approve call, matching `operator-approvals-client.ts`. Also: agent tools resolved their broadcast from the plugin runtime's gateway-request scope, an AsyncLocalStorage set only around gateway RPCs and plugin HTTP routes. An agent turn started from a channel, cron, or heartbeat therefore wrote the document without emitting `plugin.dashboard.changed`, so an open Control UI never saw the edit — the feature's headline promise. The gateway broadcast is server-lifetime, so the plugin now remembers it in a single slot and agent tools fall back to it. * docs(web): document dashboard workspaces, provenance, and the custom-widget sandbox * fix(dashboard): agent-tool ergonomics + close two approval-boundary gaps From a source-blind agent driving the dashboard_* tools with nothing but their schemas, and from a Codex review of the hardening delta. - dashboard_widget_update could never succeed. It passed its whole parameter record to the patch reader, whose allowlist rejects the very `tab`/`id` keys the tool's own schema marks required, so every call died on "unexpected param: tab". Its test only ran Value.Check against the schema and never executed the tool. - dashboard_data_read surfaced an `rpc` binding as a thrown error, though its description promised `binding_client_resolved`. It now returns that as a result the model can act on. - Valid widget kinds and the rpc allowlist were undiscoverable: a model saw only "builtin:<name> or custom:<name>" and "Allowlisted gateway read method", then brute-forced ~40 calls against errors that named no alternatives. Both schemas and both validator errors now enumerate them, and the kind description says what each builtin renders and which binding id it reads. widget_move documents that grid and toTab are exclusive; widget_scaffold says an operator must approve, because no agent tool can. - workspace.replace could mint a pending registry entry for a name that was never scaffolded. An operator could then approve a widget whose code did not exist yet, and the agent could write it afterwards. Registry entries now come from dashboard_widget_scaffold and nowhere else, and approve refuses a name with no manifest on disk. - dashboard.widget.approve answered with the whole workspace document, so a connection holding only operator.approvals could read it through the approvals door. It now returns the registry entry it changed. * fix(dashboard): approval pins the code it approves Codex review found the scaffold-before-approval gate still nameable rather than binding: approve only proved that widget.json parsed, and the Control UI loaded a hardcoded index.html rather than the manifest's entrypoint. An agent could scaffold a widget, win approval on an innocuous or absent entrypoint, then write the real payload afterwards — code appearing after the human said yes. Approval now hashes every servable file in the widget directory and stores the digests on the registry entry, refusing a manifest whose declared entrypoint is missing. The asset route re-hashes each file it reads and 404s anything that does not match, so a file edited or added after approval never reaches a browser. The Control UI loads the manifest's entrypoint, which is the file that was hashed. The content-type allowlist moves to manifest.ts so the set of files approval hashes and the set the route can serve cannot drift apart. Proof, against a running gateway: scaffold -> 404, approve -> 200, rewrite index.html -> 404, add late.js -> 404. * fix(dashboard): parse the approved manifest from the bytes that were hashed Codex found a TOCTOU in the approval path: it loaded and validated widget.json, then walked the directory again to compute the digests. An agent could swap widget.json between the two reads, so the operator validated one entrypoint while the digest froze — and the Control UI later mounted — a different one. snapshotApprovedWidget now reads the widget directory once: it hashes every servable file, parses the manifest out of the same widget.json bytes it hashed, and requires the declared entrypoint to be among them. Proof, against a running gateway: approve -> index.html 200; rewrite widget.json to point at evil.html and drop evil.html in -> both 404. * fix(dashboard): cap approval asset reads; bound the grid fallback search Two findings from the fourth Codex pass. Approval hashes agent-authored files that are untrusted until it runs, and read each one into memory with no size check — dropping one huge .png into a scaffold directory would stall or OOM the gateway during approve. Sizes are now checked before the read, with a 2 MB per-file and 8 MB total cap. nearestFreeSlot searched one band below the lowest occupied row, so a crowded layout near the bottom could return y=500 as the closest free slot: a placement the store rejects, which the UI applies optimistically and then snaps back. The search now stops at the last row a widget of that height can legally occupy. * fix(dashboard): refuse oversized widget assets before reading them Approved widget files stay writable and the asset route is unauthenticated, so swapping an approved small file for a very large one made every GET buffer the whole file before the digest check rejected it. The route now refuses anything past the same per-file cap approval enforces, on the stat it already performs. * fix(dashboard): enforce widget approval boundaries * docs(changelog): note modular dashboard workspaces * fix(dashboard): enforce static custom-widget data boundary * fix(dashboard): satisfy UI lint * test(dashboard): avoid legacy proto access * feat(dashboard): make plugin opt-in * docs(dashboard): refresh workspaces map * refactor(workspaces): standardize plugin naming * fix(workspaces): make widget prompt sends idempotent * docs(workspaces): fix internal path references * test(workspaces): make prompt assertion lint-safe * test(workspaces): type prompt request mock * fix(workspaces): harden approval and binding boundaries * test(workspaces): complete stale binding client mock * fix(workspaces): harden widget file boundaries * fix(workspaces): scope custom widget capabilities * fix(workspaces): align approval provenance * fix(workspaces): close branch contract gaps * test(workspaces): complete builtin context fixtures * fix(workspaces): aggregate overview usage * chore(workspaces): defer release note * chore(workspaces): refresh i18n metadata --------- Co-authored-by: 100yenadmin <239388517+100yenadmin@users.noreply.github.com>
105 lines
5.0 KiB
Markdown
105 lines
5.0 KiB
Markdown
---
|
|
summary: "Agent-composable Workspaces in the Control UI"
|
|
read_when:
|
|
- Building or rearranging workspace tabs and widgets
|
|
- Letting an agent compose a workspace
|
|
- Reviewing the custom-widget approval and sandbox model
|
|
title: "Workspaces"
|
|
---
|
|
|
|
The **Workspaces** tab in the [Control UI](/web/control-ui) is a surface you and your
|
|
agents arrange together. Tabs, widgets, their positions on a 12-column grid, and their
|
|
data bindings all live in one document. Anything that can edit that document can compose
|
|
the workspace: you, the `openclaw workspaces` CLI, or an agent calling `workspace_*` tools.
|
|
|
|
Every write goes through the same validated path, so a human's layout and an agent's
|
|
layout cannot diverge. Each accepted write bumps a version and broadcasts
|
|
`plugin.workspaces.changed`, so an agent's edit appears in an already-open browser without
|
|
a reload.
|
|
|
|
## Enable Workspaces
|
|
|
|
The bundled Workspaces plugin is disabled by default. In the Control UI, open **Plugins**,
|
|
find **Workspaces**, and select **Enable**. You can also enable it from the CLI:
|
|
|
|
```sh
|
|
openclaw plugins enable workspaces
|
|
```
|
|
|
|
Enabling the plugin adds the **Workspaces** tab and makes the `openclaw workspaces` CLI
|
|
and `workspace_*` agent tools available. Disabling it removes those surfaces without
|
|
deleting the workspace database or widget assets.
|
|
|
|
## The default workspace
|
|
|
|
On first load you get an **Overview** workspace: cost and token cards, instance health,
|
|
sessions, cron status, and an activity feed. It is ordinary workspace content — drag it,
|
|
collapse it, hide it, or delete it.
|
|
|
|
## Built-in widgets
|
|
|
|
Nine trusted widgets ship with the plugin and render as first-party UI:
|
|
|
|
`stat-card`, `markdown`, `table`, `iframe-embed`, `sessions`, `usage`, `cron`,
|
|
`instances`, `activity`.
|
|
|
|
Widgets declare data through **bindings**, they never fetch on their own:
|
|
|
|
| Binding | Resolves to |
|
|
| -------- | --------------------------------------------------------------------------------------------------------- |
|
|
| `static` | A literal value stored in the document (8 KB max). |
|
|
| `file` | A JSON, Markdown, or CSV file under `<stateDir>/workspaces/data/`, optionally narrowed by a JSON pointer. |
|
|
| `rpc` | One of a fixed allowlist of read-only gateway methods, resolved by the trusted Control UI. |
|
|
|
|
The `file` binding is the simplest way to put your own numbers in a workspace: write a
|
|
JSON file into the data directory and point a `stat-card` at it.
|
|
|
|
## Provenance
|
|
|
|
Tabs and widgets carry a `createdBy` stamp — `user`, `system`, or `agent:<id>` — set from
|
|
whoever made the write. It cannot be supplied by the caller, so an agent cannot label its
|
|
work as yours, and the "AI" chip on an agent-authored widget always means what it says.
|
|
|
|
## Custom widgets
|
|
|
|
An agent can author a real HTML widget with `workspace_widget_scaffold` (or you can, with
|
|
`openclaw workspaces widget-scaffold <name>`). Agent-authored code is treated as hostile:
|
|
|
|
- A scaffolded widget enters the registry as **pending**. No iframe is created, and the
|
|
asset route returns 404 for its files, until an operator approves it.
|
|
- Approval is a separate decision from editing a layout: `workspaces.widget.approve`
|
|
requires the `operator.approvals` scope, the same scope that guards exec approvals.
|
|
- An approved widget renders in an `<iframe sandbox="allow-scripts">` — never
|
|
`allow-same-origin` — so its origin is opaque and it cannot reach the parent's DOM,
|
|
storage, or cookies.
|
|
- Its assets are served with `connect-src 'none'`, blocking script networking such as
|
|
`fetch`, XHR, and WebSockets. It holds no credential and never talks to the gateway.
|
|
- Data reaches it only through a versioned `postMessage` bridge. Custom code can receive
|
|
declared `static` bindings, which are already agent- or operator-authored workspace
|
|
values. RPC and file bindings stay in trusted built-in widgets: browsers allow a
|
|
sandboxed child to navigate its own frame, so privileged data is never posted into
|
|
agent-authored HTML.
|
|
|
|
Sending a prompt into chat from a widget additionally requires a manifest capability, a
|
|
per-invocation confirmation quoting the exact text, and passes a rate limit.
|
|
|
|
## CLI
|
|
|
|
```sh
|
|
openclaw workspaces tabs list
|
|
openclaw workspaces tabs create --title Financials
|
|
openclaw workspaces widget-scaffold revenue-chart --title "Revenue Chart"
|
|
openclaw workspaces widget-approve revenue-chart
|
|
```
|
|
|
|
`widget-approve` needs a device paired with the `operator.approvals` scope; approving from
|
|
the Control UI does not, because the browser already holds it.
|
|
|
|
## Storage
|
|
|
|
The workspace document, the custom-widget registry, and a 20-entry undo ring live in
|
|
`<stateDir>/workspaces/workspaces.sqlite`. Agent-authored widget assets stay on disk under
|
|
`<stateDir>/workspaces/widgets/<name>/`, and file-binding data under
|
|
`<stateDir>/workspaces/data/`, because an agent authors those with ordinary file tools and
|
|
the widget route serves their bytes.
|