How to Manage OpenClaw Agents with Studio's Web Dashboard

OpenClaw crossed 346,000 GitHub stars by April 2026 with over 500,000 running instances across 82 countries, yet the built-in Control UI remains a localhost admin surface that the official docs warn against exposing publicly. For a single agent on your laptop, that's fine. For a team running multiple agents across environments, the gap between "works locally" and "works for the team" is where problems live.

OpenClaw Studio is a community-built Next.js web dashboard (2,000+ GitHub stars, 303 forks, 661 commits on main) that connects to your OpenClaw Gateway and adds features the native UI doesn't offer: tool-call visualization, thinking-trace rendering, persistent event replay via SQLite, and a server-owned control plane that keeps your gateway token out of the browser. The project is listed in the awesome-openclaw community directory and actively maintained on GitHub at grp06/openclaw-studio.

The architecture runs a single WebSocket connection from the Studio server to your Gateway, then fans out to browser clients through HTTP routes and Server-Sent Events. Your gateway credentials stay server-side. SSE replay works across page refreshes. Multiple team members can watch the same agent fleet without each opening a direct gateway connection. This is the core design decision that separates Studio from the native UI: the browser never talks to the gateway directly.

Studio reads its configuration from a local settings file and persists runtime state in a local SQLite database. It doesn't replace the gateway, and it doesn't run agents. It's a management layer that makes the gateway's capabilities accessible through a browser.

The broader OpenClaw ecosystem now has nine or more community-built dashboards, from Mission Control's Kanban-based task management to lightweight zero-dependency monitors. Studio carves out a specific niche: it's the dashboard built for teams that want the gateway's full feature set exposed through a proper web application, with durable event storage and server-side security by default.

The native Control UI ships inside the OpenClaw Gateway and runs automatically on the gateway's default port. Built with Vite and Lit, it provides chat, configuration management, and execution approvals. It's the fast way to get a visual interface for a local gateway. Passwords live in browser sessionStorage and don't persist across page reloads. It works well for quick local checks, but it wasn't designed for team use or remote access.

Studio takes a different architectural approach. The browser never talks directly to the gateway. Instead, the Studio Node.js server maintains a persistent WebSocket upstream, and the browser communicates with Studio through standard HTTP and SSE endpoints. This server-owned control plane model changes several things:

• Gateway tokens stay on the server and are redacted from API responses
• SSE streaming replays from the last known event ID, so refreshing the page doesn't lose conversation context
• Multiple browsers can connect simultaneously without multiplying gateway connections
• The STUDIO_ACCESS_TOKEN environment variable protects the Studio interface when bound to a public address

Studio also adds capabilities the native UI doesn't have. Tool-call visualization renders the full request and response for every tool invocation. Thinking-trace rendering shows the model's chain-of-thought reasoning inline with chat messages. The cron job configuration UI lets you set up and monitor scheduled agent tasks. Event replay means you can open the dashboard hours after something happened and scroll back through the full event history.

In practice, the native UI is the right choice for checking on a single local agent during development. Studio is what you reach for when managing agents across machines, when approval workflows need to survive browser refreshes, or when multiple team members need to watch the same fleet. Both tools connect to the same gateway and see the same agents. You can run them side by side without conflicts.

Studio supports three deployment patterns, each suited to a different team setup. The project README documents all three with specific configuration examples.

Local Gateway and Local Studio

Both the gateway and Studio run on your development machine. Studio connects to the gateway at localhost over WebSocket by default. You start Studio with npm run dev and open http://localhost:3000 in your browser. This is the simplest path for individual developers testing agents locally. No tunneling, no tokens, no remote configuration. Everything runs on the same machine and communicates over localhost.

Cloud Gateway with Local Studio

Your gateway runs on a remote server while Studio stays on your laptop. You connect the two through Tailscale Serve (using wss://<gateway-host>.ts.net) or SSH tunneling as an alternative. This pattern works well for teams that keep a gateway running 24/7 on a VPS but want each developer to manage their own Studio instance. Since the gateway token stays on your local Studio server, you avoid credential exposure over the network. Each developer gets their own view of the shared agent fleet without sharing browser sessions.

Full Cloud Deployment

Gateway and Studio both run on the same VPS, communicating locally over WebSocket. You expose Studio to the internet through Tailscale HTTPS for browser access. This is the "always-on" setup for teams that want a persistent dashboard accessible from any device. When binding Studio to a public address, the STUDIO_ACCESS_TOKEN environment variable is required, and the README warns against skipping it. You authenticate once by visiting /?access_token=your-token in the browser, and the session persists from there.

The quick-start installation path works for all three patterns:

npx -y openclaw-studio@latest

This pulls the latest release and starts the server. Configure the upstream gateway URL through the NEXT_PUBLIC_GATEWAY_URL environment variable or through the local settings file. Studio requires Node.js 20.9 or later, with the current LTS release recommended.

Give your OpenClaw agents persistent cloud storage

50GB free workspace with MCP access. Store agent output, share with clients, and keep audit trails across sessions. No credit card required.

Sign Up Free

Beyond deployment flexibility, Studio brings specific capabilities that the native UI and most community dashboards don't provide.

Tool-Call Visualization

When an agent executes a tool call, Studio renders the full request and response in the chat interface. You can see exactly what parameters the agent passed, what the tool returned, and how the agent used the result to decide its next step. For debugging agent behavior, this is far more useful than reading raw JSON logs. You can trace why an agent made a particular decision by following the tool-call chain visually.

Thinking-Trace Rendering

The model's chain-of-thought reasoning renders inline with chat messages. Instead of seeing only the final output, you follow the agent's reasoning process as it evaluates options, considers constraints, and arrives at an action. This is particularly valuable when an agent does something unexpected. Rather than guessing why, you can read the trace and see exactly where its reasoning diverged from what you expected.

Approval Workflows with Persistence

Studio surfaces the gateway's approval system through a dedicated interface. When an agent requests permission to run a destructive or sensitive action, the approval appears in Studio with full context about what the agent wants to do and why. You approve, deny, or add conditions. These approval states persist in Studio's SQLite database, so they survive browser refreshes and server restarts. For production deployments, this persistence is the difference between a useful safety gate and one that resets every time someone closes their laptop.

Event Replay and Durability

Every runtime event is stored in Studio's SQLite projection store. The SSE streaming endpoint supports replay from any Last-Event-ID, so reconnecting after a network drop picks up exactly where you left off. Without a Last-Event-ID, Studio replays a recent tail window from the outbox head, giving you immediate context when opening the dashboard cold. You can also scroll back through historical events to review what happened while you were away.

Cron Job Configuration

For agents that run on schedules, Studio provides a UI for configuring and monitoring cron jobs. Set up recurring tasks, view execution history, and adjust schedules without editing gateway configuration files directly.

Gateway-First Data Model

Agents, sessions, and configuration all live in the gateway. Studio stores only UI settings and its runtime event projection. This means you can delete Studio's local database, reconnect, and pick up where you left off without losing agent state. The gateway is always the source of truth, and Studio is a read-heavy view layer on top of it.

Studio manages your agent fleet, but it doesn't solve the question of what happens to the files agents produce. When agents generate reports, process documents, or build client deliverables, those outputs need to live somewhere durable, shareable, and organized. Local filesystems work during development. They break down when clients need access, when multiple agents write to the same project, or when you need an audit trail of who created what and when.

Cloud workspaces fill this gap. Fast.io provides shared workspaces where agents and humans collaborate on the same files. Agents connect through the Fast.io MCP server using Streamable HTTP at /mcp or legacy SSE at /sse, with 19 consolidated tools covering storage, AI, sharing, and workflow operations.

The practical workflow looks like this: Studio manages your agent fleet and surfaces approval requests. Your agents do their work. When they produce output, they write files to Fast.io workspaces where clients, teammates, or other agents can access them. Intelligence Mode auto-indexes uploaded files for semantic search and citation-backed chat, so anyone with workspace access can ask questions about the agent's output without reading every document manually.

For teams running multiple agents that might write to the same workspace, file locks prevent conflicts. An agent acquires a lock before modifying a file, then releases it when finished. Other agents wait rather than overwriting each other's work. Webhooks notify downstream systems when files change, so you can build reactive workflows without polling.

Ownership transfer is useful at the end of an engagement. An agent creates an organization, builds out workspaces, populates them with deliverables, then hands the whole structure to a human client. The agent keeps admin access for ongoing updates while the client gets full ownership. No zip archives, no shared drive links, no manual file transfers.

The agent free plan includes 50GB of storage, 5,000 monthly credits, and 5 workspaces with no credit card and no expiration. That covers most development workflows and smaller production deployments. Pricing details cover higher tiers for teams with larger needs.

The fast path from zero to a working Studio dashboard takes about five minutes, assuming you already have an OpenClaw Gateway running.

Start with the one-line installer:

npx -y openclaw-studio@latest

This pulls the latest release and starts the development server. Open http://localhost:3000 in your browser. Studio attempts to connect to a local gateway over WebSocket by default.

If your gateway runs elsewhere, set the upstream URL before starting:

NEXT_PUBLIC_GATEWAY_URL=wss://your-gateway.ts.net npm run dev

For source installations, when you want to customize Studio or contribute back:

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

Studio runs a dependency repair check on startup in development mode. Production mode validates dependencies without mutating them. If you hit NODE_MODULE_VERSION mismatches with better-sqlite3 (common when switching Node.js versions), run npm rebuild better-sqlite3 to rebuild the native bindings. The Studio README also documents npm run verify:native-runtime:repair for more thorough native module recovery.

For public deployments, always set a STUDIO_ACCESS_TOKEN. Visit /?access_token=your-token once in the browser to authenticate, and the session persists from there. Without this token, anyone who can reach the Studio URL has full access to your agent fleet.

Once connected, you see your gateway's agents, active sessions, and pending approvals immediately. The event stream starts in real time without polling. If you've enabled cron jobs on any agents, those schedules appear in the cron configuration panel. The full UI workflow guide is available in the project's docs/ui-guide.md for detailed navigation through each feature.