ClawApp: A Browser-Based Mobile Chat Client for OpenClaw Agents

The localhost problem ClawApp exists to solve

OpenClaw's Gateway listens on 127.0.0.1:18789 by default. That is the right default for a desktop agent, and it is also the reason a phone on the same WiFi cannot reach it. ClawApp is the missing hop: a Node server that speaks WebSocket to the browser and WebSocket to the Gateway, listening on port 3210 in between.

The audience is narrow and specific. You need an OpenClaw Gateway already running on a computer you control, Node.js 18+ or Docker, and a phone. If you do not run OpenClaw, nothing here applies to you. The README recommends the Chinese translation of OpenClaw, but the client itself is not tied to that fork.

The pitch is that the browser is the client. There is no app install for the H5 path, and the README describes a PWA mode where the page is added to the home screen and works offline. An Android APK exists as well, built with Capacitor and GitHub Actions, but it is an alternative packaging of the same frontend rather than a separate product.

How the proxy and Ed25519 handshake actually fit together

The README gives the data flow directly: phone browser over WS or WSS to the ClawApp server on port 3210, then the server over WebSocket to the OpenClaw Gateway on port 18789. The browser never talks to the Gateway. That single fact explains most of the design.

Because the proxy sits in the middle, it can do the authentication the browser cannot. The README states the server performs the Ed25519 device signing handshake automatically and is compatible with OpenClaw 2.13+. This matters: the Gateway expects a signed device identity, and a plain browser page has no way to produce one. ClawApp holds that responsibility server-side.

On the client side the README lists streaming replies, image send and receive, Markdown rendering with code highlighting and XSS protection, a slash-command panel for /model, /think and /new, tool-call status display, multi-agent selection when creating a session, theme switching, and a Chinese and English toggle. Offline history is persisted in IndexedDB, and the README says messages are deduplicated and reconnected without flicker. Those are the parts that make it feel like a chat app rather than a terminal in a browser tab.

Installing ClawApp with Docker and connecting a phone

The README offers a one-line install script for Mac, Linux and Windows PowerShell, and a Docker path it labels as recommended. The Docker path is the one worth walking through because every value it needs is visible.

Clone the repository and create a .env file in the project root. PROXY_TOKEN is the password your phone will send. OPENCLAW_GATEWAY_TOKEN is the Gateway's own token, which the README says lives in ~/.openclaw/gateway.yaml.

PROXY_TOKEN=my-secret-token-123
OPENCLAW_GATEWAY_TOKEN=your-gateway-token

If you are behind Tailscale Funnel, the README says to use password mode instead, via OPENCLAW_GATEWAY_PASSWORD, and notes it takes priority over the token. Then build and start the container.

docker compose up -d --build
docker compose logs -f

The compose file maps 3210:3210 and sets OPENCLAW_GATEWAY_URL to ws://host.docker.internal:18789, with an extra_hosts entry mapping host.docker.internal to host-gateway so the container can reach the Gateway on the host. On the phone, open http://your-computer-ip:3210, enter the server address and the PROXY_TOKEN value, and connect. The README lists how to find that IP: ifconfig on Mac, ipconfig on Windows, ip addr on Linux.

There is a non-Docker path too: git clone, npm run install:all, npm run build:h5, copy server/.env.example to server/.env, fill in the token, then npm start. The README also documents PM2 for keeping it running, with pm2 start server/index.js --name clawapp followed by pm2 save and pm2 startup.

What breaks: HTTP, voice input and the changeme default

Voice input is the clearest limitation, and the README is explicit about it. Browsers require a secure context for microphone access, so the voice feature only works over HTTPS. On a plain LAN address like http://192.168.x.x:3210 the button is there but the microphone will not be granted. The README recommends cftunnel for this reason, since it provides automatic HTTPS, and warns that an SSH tunnel is HTTP by default and therefore loses voice input unless you put Nginx with SSL in front.

That shapes the whole remote-access section. SSH tunneling needs a public server with GatewayPorts yes in /etc/ssh/sshd_config and port 3210 open in the firewall. Nginx reverse proxying needs a certificate and the Upgrade and Connection headers set, plus a long proxy_read_timeout because the connection is a WebSocket. cftunnel is the one-command option but depends on Cloudflare. None of these is a single checkbox.

The default token is the other sharp edge. The compose file reads PROXY_TOKEN with a fallback of changeme. If you start the container before writing .env, the proxy is listening on 3210 with a guessable password. The README does not document a rollback procedure for a bad deployment, and the repository's license field is not stated in the README even though package.json declares MIT.

ClawApp versus a plain SSH tunnel or a generic chat UI

The honest alternative for a single technical user is not another app. It is an SSH tunnel plus a terminal, or Tailscale plus whatever client you already have. That approach requires no extra service on port 3210 and no third party. What it does not give you is a phone-shaped interface: no image upload from the camera roll, no slash-command panel, no streaming Markdown rendering, no offline history in IndexedDB. If those are what you want, the tunnel alone will not produce them.

The other alternative is a general-purpose chat frontend pointed at an OpenAI-compatible endpoint. That works when your agent exposes such an endpoint. OpenClaw's Gateway is a WebSocket service with a signed device handshake, so a generic client cannot complete the connection without the proxy. ClawApp's value is that it implements that handshake for you, and its cost is that you now run a second network service whose only job is to hold your Gateway credentials.

Maintenance, licensing and what the repository tells you

The last push to the default branch was on 2026-05-07, the same day v2.0.0 was tagged. The repository is not archived. Releases before that were v1.9.0 on 2026-03-24 and v1.8.1 on 2026-03-08, so the project shipped three releases in roughly two months and then went quiet for the rest of the period covered here. Treat that as a cadence fact, not a verdict.

package.json declares MIT and names 武汉晴辰天下网络科技有限公司 as author. The repository's own license field is listed as unknown, so if you need certainty about the terms, read the LICENSE file in the repository rather than the package metadata. Nothing here is legal advice.

Upgrade cost is mostly your own deployment. The Dockerfile builds the H5 frontend in a node:22-slim stage and copies the output into a runtime image that runs node server/index.js, so a rebuild is required for frontend changes. The README does not describe a migration path between server versions or a versioned API between ClawApp and the Gateway, which means an OpenClaw Gateway upgrade is the event most likely to break the handshake.

Editorial conclusion

Adopt ClawApp if you already run an OpenClaw Gateway on a machine you control and want phone access without building a client. Do not adopt it if you have no OpenClaw Gateway, or if you expect the proxy to be safe on an untrusted network, since the README's remote options all assume you add HTTPS yourself. Verify first that your Gateway version matches the Ed25519 signing handshake the README says is compatible with OpenClaw 2.13+, and set PROXY_TOKEN before the first docker compose up -d --build, because the compose file falls back to changeme when the variable is unset.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. qingchencloud/clawapp on GitHub
4. README
5. Releases