Skip to main content
Use the System panel to set the default command-approval posture for OpenClaw agents and to see (and update) your OpenClaw install. It is a small panel: two cards, nothing else. The OpenClaw Gateway process controls, the default-model picker, and the provider API keys used to live here and have each moved to the surface that owns them; see What moved, and where it went below. Everything on this page is MaintenancePanel (features/maintenance/) talking to the /api/system/* routes. The panel reads GET /api/system/status on mount, its Command Approval section reads GET /api/system/openclaw-config and writes back through PATCH /api/system/openclaw-config, and Check for Updates streams SSE POST /api/system/install-openclaw. It never calls POST /api/system/gateway.

​
Prerequisites

The System panel is built for the OpenClaw path. The Command Approval section renders only when a live Gateway client is connected and the current value could be read from openclaw.json; if you are running native-only (no Gateway), the panel is just the System Info card.
  • OpenClaw installed (the System Info section shows the detected version, or “Not installed”).
  • The dashboard running (clawboo); the System panel lives in the Settings modal.

​
Where it lives

Open Settings (the gear at the bottom of the sidebar, or Cmd/Ctrl + ,), then System under the System group. The panel is a single scrollable column of two cards: Command Approval and System Info.

​
What moved, and where it went

Earlier releases stacked seven sections here. Five of them now live on the surface that owns them, so the setting sits next to the thing it configures instead of in a catch-all panel:
There is no agent-coordination switch anywhere in the dashboard. Agent-to-agent tooling is enabled unconditionally: onboarding writes tools.agentToAgent.enabled: true (and tools.sessions.visibility: "all") into openclaw.json when it configures OpenClaw, and team deploys re-assert it. It is the core of the product, not a togglable option.

​
Steps

​
Set the default command approval

The Command Approval section is one dropdown, and it renders only while a Gateway client is connected. It sets tools.exec.ask in openclaw.json, the fleet-wide default posture for OpenClaw agents before they run a shell command. It is a default, not an override. A Boo with its own per-agent entry in the Gateway’s approvals store follows that entry instead, and Clawboo now writes one as it creates an OpenClaw Boo: Ask for Unknown, or whichever of the three postures below the caller asked for. So this dropdown no longer loosens a newly created Boo: set Run Freely here and a Boo created with that default still asks about a command it has not been allowed before, because its own entry says to. See What a new Boo is allowed to run.
  1. Pick an option. The dropdown updates immediately (optimistically) and disables itself while the write is in flight.
  2. The panel sends PATCH /api/system/openclaw-config with { exec: { ask } }, and a toast confirms Default command approval set to ”…”.
  3. If the write fails, the dropdown snaps back to its previous value and you get a Failed to update Gateway config toast.
After a successful write the panel makes a best-effort config.get() call on the Gateway client. That call is advisory: it is wrapped in its own try/catch, so a disconnected Gateway changes nothing about the outcome, and the new value is already on disk in openclaw.json either way.
This is the fleet-wide default, and it only decides for a Boo that has no entry of its own. Set or change one agent’s entry in its detail view’s Permissions tab, under Execution Permissions; that posture is per-agent, is written to the Gateway, and takes effect on the agent’s next message. See Approvals for what happens when an agent does ask.

​
Check version and updates

The System Info section shows the OpenClaw version (or “Not installed”), the Node.js version, OpenClaw’s state dir (~/.openclaw by default), and whether openclaw.json was found, all from a single GET /api/system/status read on mount. This card does not poll; it re-reads only after a successful update. Check for Updates runs the OpenClaw installer in place: it streams POST /api/system/install-openclaw (which runs npm install -g openclaw@~2026.9) as SSE, renders every progress and output line in the update log below the button, and on success re-fetches status so the version row shows the new value.

​
Options / variations

​
Verify it worked

  • Command Approval: a toast reads Default command approval set to ”…”; GET /api/system/openclaw-config returns the new value at config.tools.exec.ask.
  • Check for Updates: the log ends with a success toast (Updated to <version>) and the System Info OpenClaw row shows the new version.

​
Troubleshooting

The Command Approval section is missing. It renders only when a Gateway client is connected and the current tools.exec.ask could be read from openclaw.json. If you are native-only, or the Gateway is stopped, it is hidden by design and the panel shows System Info alone.
Nothing here starts the Gateway. The System panel no longer controls the Gateway process. Go to Settings → Runtimes and read the OpenClaw row. If the Gateway is running, expand the row’s Manage body and use Restart in its Gateway block. If the Gateway is stopped there is no Manage body at all: the row reads Disconnected and its action is Reconnect. That reveals a short body with a Reconnect OpenClaw button, which reruns the inline setup non-destructively (your existing openclaw.json and credential are reused, nothing is re-asked) and starts the Gateway back up. The backing route is unchanged: POST /api/system/gateway with { action: "start" | "restart" } is an SSE stream that polls the port for up to 60 seconds, and { action: "stop" } is a plain JSON call returning { ok: true, stopped: true } on success.
Check for Updates reinstalls globally. It runs npm install -g, which can hit EACCES on a system Node install. If the log shows a permission error, prefer a Node version manager (nvm/fnm) or Homebrew over sudo. Pinning is to openclaw@~2026.9 to stay config-compatible with this Clawboo.

​
See also

  • Connecting runtimes, the Runtimes panel and the Providers hub that now hold the gateway controls, the default-model picker, and the provider keys
  • OpenClaw, the Gateway runtime, device pairing, and channels
  • Approvals, the queue that tools.exec.ask feeds
  • Boo Zero, where the display name, global brief, and team rules editors live
  • /api/system/* reference, full request/response shapes for every route on this page
Last modified on September 15, 2026