OpenClaw Studio: a web dashboard for OpenClaw agents across local and cloud setups

What Studio adds on top of the OpenClaw Control UI

OpenClaw agents can be managed through the command line or through the OpenClaw Control UI. Studio is a third option: a web dashboard for agent creation, cron job configuration, exec approval review, and chat with running agents, all from one browser page.

A concrete difference between Studio and the Control UI is the authentication model. The Control UI can use Tailscale identity headers, but Studio always needs a Gateway token, even when both are behind the same Tailscale network. Studio does not inherit the ambient identity that Tailscale provides, and anyone who expects SSO-style access from their tailnet will need to manage the token separately.

The target user is an engineer who prefers a web interface for day-to-day agent work and has an OpenClaw Gateway running locally or on a cloud VM. Without an active Gateway, Studio has nothing to connect to and no function.

Browser talks to Studio over HTTP+SSE; Studio talks to Gateway over one WebSocket

The README documents two primary connection paths. From the browser to Studio: HTTP requests plus server-sent events on the endpoints /api/runtime/*, /api/intents/*, and /api/runtime/stream. From Studio to the Gateway: one server-owned WebSocket opened by the Studio Node process.

That second path is what makes the localhost wording non-obvious. When the README says the upstream should stay at ws://localhost:18789, it means localhost on the Studio host, not localhost on the engineer's laptop. A Studio process running on a cloud VM forwards the WebSocket to whatever is listening at 18789 on that VM. Opening Studio from a laptop browser does not change that.

SQLite (via better-sqlite3 12.6.2) backs the control plane. Studio stores a runtime projection and a replay outbox in ~/.openclaw/openclaw-studio/runtime.db. On a page refresh or process restart, Studio replays from that outbox so SSE state is consistent rather than starting empty. Keeping replay deterministic across restarts is the documented design goal; failure modes under edge-case load are not described.

Installing with npx and connecting a local Gateway

For a first run where both Studio and the Gateway are on the same machine, the README recommends three commands:

npx -y openclaw-studio@latest
cd openclaw-studio
npm run dev

After that, open http://localhost:3000 in a browser. In Studio's settings, set the upstream URL to ws://localhost:18789 and paste the Gateway token. The README gives one way to retrieve that token:

openclaw config get gateway.auth.token

Alternatively, the optional setup helper writes the saved gateway URL and token for the Studio host without opening the UI:

npm run studio:setup

Building from source replaces the npx step with a git clone and npm install:

git clone https://github.com/grp06/openclaw-studio.git
cd openclaw-studio
npm install
npm run dev

Node.js 20.9 or newer is required. The package.json engines field is explicit on that floor.

One thing to watch before first start: npm run dev runs the verify:native-runtime:repair script automatically before the server starts. The production command npm run start runs verify:native-runtime:check instead, which checks but makes no changes. If the check fails on start, the server will not come up.

Reaching a cloud Gateway via Tailscale Serve or SSH tunnel

When the Gateway is on a remote host, Studio still needs a route to port 18789. Two paths exist for scenario B, where Studio runs on a laptop.

With Tailscale Serve, run this on the Gateway host:

tailscale serve --yes --bg --https 443 http://127.0.0.1:18789

Then set Studio's upstream URL to wss://<gateway-host>.ts.net. With an SSH tunnel, run this from the laptop instead:

ssh -L 18789:127.0.0.1:18789 user@<gateway-host>

After that, Studio's upstream URL goes back to ws://localhost:18789, which now forwards through the tunnel to the remote host.

For scenario C, where both Studio and the Gateway live on the same cloud VM, keep the upstream local (ws://localhost:18789) and expose Studio itself with Tailscale Serve:

tailscale serve --yes --bg --https 443 http://127.0.0.1:3000

Access then goes through https://<studio-host>.ts.net. One constraint applies to scenario C: avoid serving Studio under a /studio subpath unless you configure the basePath option and rebuild, because the Next.js routing will break otherwise.

STUDIO_ACCESS_TOKEN is required the moment Studio binds beyond loopback

Studio's security boundary is the network binding. Loopback addresses (127.0.0.1, ::1, localhost) do not require STUDIO_ACCESS_TOKEN. Anything else does: HOST=0.0.0.0, HOST=::, or any non-loopback hostname or IP. What happens when the token is absent and the host is public-facing is not documented; the safest reading is that the dashboard is open to any visitor.

Authentication for a token-protected Studio is handled through a URL parameter. Opening /?access_token=... once from each new browser sets a Studio cookie for subsequent visits. No session management is described beyond that cookie, no account system exists at the Studio level, and no per-user permission layer is documented.

Two environment variables in .env.example are worth noting for non-loopback deployments. OPENCLAW_GATEWAY_SSH_TARGET sets the SSH target for gateway-host operations (used when deleting agents to move workspace state to ~/.openclaw/trash on the Gateway host). OPENCLAW_GATEWAY_SSH_USER overrides the SSH user when the target is derived from the gateway URL, with a default of ubuntu.

Startup guards verify native runtime dependencies before dev and prod differ

The package.json scripts show an asymmetry between the dev and production startup paths that matters when something fails on first run.

npm run dev (and npm run dev:turbo) trigger verify:native-runtime:repair before the server starts. Repair mode finds missing or broken native runtime dependencies and fixes them in place. That means a fresh checkout usually starts without a manual install step.

npm run start, the production command, triggers verify:native-runtime:check instead. Check mode only reports problems; it does not mutate dependencies. A broken native dependency fails the startup with an error rather than self-healing. The difference is intentional: production environments should not modify their own dependencies at runtime, and a failed check produces a clear failure message rather than a silent partial repair.

The state directory layout is worth keeping in mind when debugging. Studio settings live at ~/.openclaw/openclaw-studio/settings.json, the runtime database at ~/.openclaw/openclaw-studio/runtime.db, and the OpenClaw config itself at ~/.openclaw/openclaw.json. All three paths can be redirected by setting OPENCLAW_STATE_DIR.

Package.json sets private:true while the recommended install path uses npx

Package.json sets "private": true, which normally prevents npm publish from working, yet the install path in the README (npx -y openclaw-studio@latest) requires the package openclaw-studio to exist on npm. Those two facts are in tension: the current source repository cannot be published as a new npm version, but the npx command succeeds by reading from an existing npm entry that predates the private flag or comes from a separate build artifact.

Nothing documents the publishing workflow, and no GitHub releases exist to trace when the flag was added or what the npm version history looks like. Someone forking this project who wants to publish their own version needs to remove the private flag from package.json before npm publish will work.

The last push was on 2026-06-26, the repository is not archived, and the project is licensed under MIT.

Editorial conclusion

OpenClaw Studio is a good fit for teams that already run an OpenClaw Gateway and want to manage agents, approve executions and view chat history from a browser instead of the command line. Skip it if you have no OpenClaw Gateway, since the dashboard has no function without one. The security gap to close before any public deployment is STUDIO_ACCESS_TOKEN: run Studio with HOST=0.0.0.0 without setting that token and any visitor to the host can access the dashboard. Verify the token requirement against the configuration docs at ~/.openclaw/openclaw-studio/settings.json before exposing Studio beyond localhost.

Frequently asked questions

Official sources

1. grp06/openclaw-studio on GitHub
2. Issues
3. License: MIT
4. README