ClawPort: A Next.js Dashboard for OpenClaw Agent Teams
Open-source AI agent command center for Claude Code agent teams. Built on OpenClaw.
At a glance
- What is it?
- ClawPort is an MIT-licensed Next.js front end that reads your OpenClaw workspace and renders agents, cron jobs, costs and memory in one browser tab. The judgement: it is a thin, gateway-dependent UI layer, so its usefulness tracks how much you already run OpenClaw rather than anything ClawPort itself decides.
- Who is it for?
- Adopt ClawPort if you already run an OpenClaw gateway and want a browser view of agents, cron jobs, costs and memory without writing your own front end. Do not adopt it if you have no OpenClaw instance, or if you need a hosted multi-user product: this is a local dashboard bound to one gateway token.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 175 days ago.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The gap ClawPort fills: a gateway with no window
OpenClaw is a gateway process. The README describes onboarding with `openclaw onboard --install-daemon`, checking it with `openclaw gateway status`, and listing scheduled work with `openclaw cron list`. That is a command line surface. Agents live as directories under `$WORKSPACE_PATH/agents/` with `SOUL.md` files, memory lives under `$WORKSPACE_PATH/memory/`, and every AI call routes through an HTTP endpoint on port 18789 by default. Nothing in that arrangement gives you an org chart, a cost chart, or a place to read team memory without opening files.
ClawPort is aimed at the person who has already committed to OpenClaw and now wants a control surface. The README frames it as a command centre for an agent team: hierarchy, cron status, chat, kanban, logs, costs, memory. The audience is narrow by construction. If you do not run OpenClaw, there is nothing for ClawPort to read. It is not a standalone agent framework and it does not ship its own model routing; the README states plainly that no separate AI API keys are needed because everything routes through your gateway.
Data flow: a Next.js app reading files and proxying to one gateway
The README's diagram is the clearest statement of architecture available. The browser talks to ClawPort, which is a Next.js application. ClawPort talks to the OpenClaw gateway, which talks to Claude. Three channels are named: text goes over `/v1/chat/completions` using streaming SSE, vision goes through a CLI call (`openclaw gateway call chat.send`), and audio goes to `/v1/audio/transcriptions` using Whisper.
The read side is separate from the AI side. ClawPort reads `$WORKSPACE_PATH/agents/` for `SOUL.md` files, `$WORKSPACE_PATH/memory/` for team memory, and shells out to `openclaw cron list` for scheduled jobs. That split matters when you debug: a broken chat is a gateway or token problem, while a missing agent is a workspace path problem. The two failure surfaces are unrelated, and the README does not describe a fallback when either one is unavailable.
The front end itself is TypeScript with React Flow powering the org map and auto-layout, according to the feature list. Conversations persist locally, and the live log stream widget is described as persisting across page navigation. Five themes (Dark, Glass, Color, Light, System) are implemented as CSS custom properties, which is a cheap way to switch appearance without a rebuild.
Getting it running: two installs, three variables
There are two things to install, and the order is not optional. First OpenClaw: `curl -fsSL https://openclaw.ai/install.sh | bash`, then `openclaw onboard --install-daemon`, then `openclaw gateway status` to confirm the URL and auth token. Second ClawPort: `npm install -g clawport-ui`. The README flags a naming trap here. The npm package is `clawport-ui`; the CLI command is `clawport`; and an unrelated package named `clawport` exists and should not be installed.
Configuration is three required environment variables. `WORKSPACE_PATH` points at the OpenClaw workspace, with the README giving `~/.openclaw/agents/main/workspace` as the default and `~/.openclaw/workspace` as a legacy alternative. `OPENCLAW_BIN` is the path to the binary, found with `which openclaw`. `OPENCLAW_GATEWAY_TOKEN` comes from `openclaw gateway status`. One optional variable, `ELEVENLABS_API_KEY`, enables voice indicators on agent profiles.
You are not expected to write these by hand. `clawport setup` auto-detects the values and writes `.env.local`, and `clawport dev` starts the dashboard on `http://localhost:3000`. The README notes a wrinkle for global installs: if the package directory is not writable, setup writes to `~/.config/clawport-ui/.env.local` instead. There is also a source route: clone the repository, then `npm install`, `npm run setup`, `npm run dev`. Custom gateway ports are described as detected automatically by `clawport setup`.
Where the design shows its limits
The dependency on a running gateway is the defining constraint. Every AI operation, including vision and transcription, is a proxy call. If the gateway is down, chat, voice and image handling stop together, and ClawPort has no documented offline mode. The dashboard is a view over a process, not a replacement for it.
Second, the configuration surface is thin. Three required variables and one optional key is easy to set up, but it also means there is little to tune. The README does not document rate limiting, retry behaviour, or what happens when a streaming SSE connection drops mid-response. Those are the questions that surface in daily use, and the supplied material does not answer them.
Third, the feature list is broad and the depth of each item is uneven. The cron monitor is described as auto-refreshing every 60 seconds, which is a concrete interval. The cost dashboard claims daily charts, per-job breakdown, model distribution, anomaly detection and cache savings, but the README gives no formula for how cost is attributed to a job or what threshold counts as an anomaly. Treat those panels as views to verify against your own gateway records rather than as accounting.
Finally, the README is truncated in the supplied material at the Agent Discovery section, so the full discovery rules are not available. If agent detection is central to your setup, read the repository's SETUP.md before relying on auto-discovery.
Alternatives and the real difference in approach
The obvious alternative is the OpenClaw CLI itself. `openclaw gateway status` and `openclaw cron list` already expose gateway health and scheduled jobs; the README's own architecture diagram shows ClawPort calling `openclaw cron list` underneath. The difference is presentation and scope. The CLI answers one question at a time and returns text. ClawPort keeps a persistent browser view with an org chart, a kanban board, a memory browser and a live log widget, and it adds chat with attachments, vision and voice. If your work is occasional checks on a handful of jobs, the CLI is fewer moving parts and one less process to keep running.
A second alternative is building a small internal dashboard against the same gateway API. ClawPort's text path is a standard `/v1/chat/completions` endpoint with SSE, so a team with front-end capacity can consume it directly. What you would be reimplementing is the collection of views: React Flow org layout, kanban state, log expansion, cost charts, markdown rendering for memory. That is a real amount of UI work, and it is the part ClawPort actually contributes. The trade is control over the data model versus not writing the interface.
Choosing between them comes down to whether you want a general-purpose agent console or a narrow script. ClawPort is the former, and it inherits the gateway's uptime as its own.
Maintenance, licence and upgrade cost
The licence is MIT, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are included. That is a permissive arrangement, and it means forking is legally straightforward. It is not legal advice; read the LICENSE file in the repository for the exact terms.
Upgrade cost has two components. The npm package is installed globally, so updates are an `npm install -g clawport-ui` away, but the README notes that a global install may write configuration to `~/.config/clawport-ui/.env.local` when the package directory is not writable. That path is worth knowing before an upgrade, because it is where your detected values live and it is easy to overlook during troubleshooting.
The second component is OpenClaw itself. ClawPort reads workspace files and shells out to the CLI, so changes in how OpenClaw lays out `agents/`, `memory/`, or the output format of `openclaw cron list` can break discovery or the cron monitor. The README's architecture is a coupling to those interfaces, not an abstraction over them. The repository shows no retrieved releases in the supplied material, so there is no published version history to weigh here; the last push date is 2026-03-24, which indicates the project is active but tells you nothing about release cadence.
What to check before you commit
Run `openclaw gateway status` first and confirm you get a URL and a token. Without that, ClawPort has nothing to connect to. Then confirm your workspace path, because the default in the README is `~/.openclaw/agents/main/workspace` with `~/.openclaw/workspace` as a legacy alternative, and a mismatch will show up as an empty org map rather than an error.
Install `clawport-ui`, not `clawport`. Run `clawport setup` and inspect where it wrote `.env.local`: either the package directory or `~/.config/clawport-ui/.env.local`. Then run `clawport dev` and open `http://localhost:3000`.
The honest summary is that ClawPort is a UI layer whose value is proportional to how much you already invest in OpenClaw. It does not add agent capability, and it cannot function without the gateway. If you run OpenClaw daily and want the org chart, cost view and memory browser in a tab, the install is three commands and a setup wizard. If you check a couple of cron jobs a week, `openclaw cron list` is still the shorter path.
Editorial conclusion
Adopt ClawPort if you already run an OpenClaw gateway and want a browser view of agents, cron jobs, costs and memory without writing your own front end. Do not adopt it if you have no OpenClaw instance, or if you need a hosted multi-user product: this is a local dashboard bound to one gateway token. Before installing, verify three things: that `openclaw gateway status` returns a URL and token, that your workspace path matches the default `~/.openclaw/agents/main/workspace` or the legacy `~/.openclaw/workspace`, and that the npm package you install is `clawport-ui`, not the unrelated `clawport` package the README warns about.
Community notes