Overview

The wiring between channels and backends, both directions. Every bot, number, and agent routes to a primary backend and falls back to a second one; a backend can serve many of them. Change a route by picking a backend on the right, then Save routing. A route pointing at a missing or disabled backend is flagged in red.

The tail of the gateway's own structured log (.clawux/logs), newest last. Phone numbers and tokens are already masked. Use this to watch a message flow through, or to see why a backend call failed, without shell access. Console output still goes to the service supervisor.

Wire a bot end to end in one flow: channel, token env, backends, optional allowlist entry. The save is scoped and the gateway hot starts the bot, so no restart is needed. Create the bot with your provider first (for Telegram: BotFather), export its token env where the gateway runs, then check it here.

1. Bot and token

   Channel Instance id Token env name
   Check token

   Not checked yet. The check confirms the env resolves in the gateway process and, for Telegram, names the bot the token belongs to.

2. Backends

   Primary backend Backup backend

   Several bots and channels can share one backend; replies always return to the conversation that asked. Need a new backend (an LLM endpoint or your own service)? Create one in Backends and it becomes selectable here immediately.

3. Access (optional)

   Allowlist entry

   Adds one recipient to this channel's allowlist. Leave blank to keep the channel's current policy.

Every bot currently configured across all channels, with its backend route and live status. Edit routing and tokens per bot on its channel page (Telegram, WhatsApp, RCS, or More channels).

Store public tunnel and RCS sender settings in ClawUX config. Secret values still stay in environment variables; this screen controls the public URL and which env var names ClawUX reads.

Send gateway-owned disclosure text before the first backend reply for each channel, bot, and conversation. Delivery is recorded separately from consent: receiving or continuing after this notice never grants optional consent.

Checking trust ledger…

ClawUX derives variable names from the current channel and backend configuration. It can add missing empty placeholders and remove obsolete placeholders only when they are empty. Existing non-empty values are always preserved. Secret values are never returned to this page.

Checking environment file…

Authorize your own user to start/stop/restart the ClawUX service without a password, so code changes can be applied (and restarted) seamlessly. This installs a narrowly-scoped polkit rule for your user and only the clawux.service unit — not passwordless root. Run the command below once in a terminal; ClawUX never performs this privileged step itself.

Each Telegram bot is an instance with its own token env and backend route. Create the bot with BotFather, export its token where the gateway runs, then check it here. Live status appears once polling starts, and each bot's backend route is shown read-only (edit it in the Routing map). New here? The Wire a Bot flow walks the whole setup.

WhatsApp uses the free Baileys transport (internal/test only; it automates WhatsApp Web and is against WhatsApp's terms, so use a burner number). Set the backend route below, then pair this gateway as a linked device.

On your phone: WhatsApp → Settings → Linked devices → Link a device, then scan the QR below.

Pairing shows here when WhatsApp is enabled on the Baileys transport (Save above first).

Each row below is one RCS agent (an RBM agent). madvamb and hermes are two separate agents, each with its own agent id, webhook secret, and backend route; Add instance creates another agent. The fields at the top of a row are that agent's own settings. An agent shows not ready until both its agent id env and webhook secret env are set, so a half-configured agent is never shown as active.

Recipients you can send RCS test messages to. In RBM a tester is invited per agent, so these are tied to the RCS agent you test with. Use E.164 format.

SMS, Slack, Discord, and the local web channel. Enable one and set its backend route; the primary channels (Telegram, WhatsApp, RCS) have their own pages. Save applies only to the channels on this page.

Backends are the AI systems that answer users' messages; each channel routes to one. A local or self-hosted service needs no key; a cloud provider (Claude, OpenAI, and similar) needs an API key, set as an environment variable on the server and named in the backend's "API key env" field below. This is separate from how ClawUX itself decides and composes the experience, which lives on the ClawUX AI page and is ClawUX config, not a backend.

ClawUX watches backend health and, when one goes down, sends you a notice with a diagnostic clue on the channels you pick here. Choose one, two, or three. This detects and reports the problem; fixing the backend stays with the backend admin. Recipients must be in the delivery allowlist (your own number normally is). Telegram is the most reliable alert path because it does not depend on any AI backend.

This is ClawUX's own AI, how it decides and composes the experience, not a backend that channels route to. Each box saves on its own. When a box uses a "custom endpoint" it means ClawUX's own model (a local or self-hosted LLM you point it at here); "Hermes" means reusing the Hermes backend for that decision instead.

Not scanned yet.

Control delivery guardrails without changing Hermes, OpenClaw, or channel adapter code.

Per-channel allowlists

Each enabled channel enforces the union of the global list above and its own entries. RCS additionally derives entries from the invited testers in Test Devices. A channel with no entries at all stays unrestricted; adding any entry restricts that channel to its list.

An empty allowed-recipient list means delivery is unrestricted. Use one value per line or comma-separated values.

Map universal UX intents to safe ClawUX primitives. Provider specific raw payloads stay out of this UI.

Map a recipient (phone number or chat id) to a display name so Activity and logs show who a delivery went to. Phone numbers match by their last 10 digits regardless of formatting; other ids match exactly. Saved to config/contacts.json — names appear on delivery records, so only add people who expect to be addressed by this gateway.

The most recent messages this gateway rendered and delivered, with the chosen primitive, render quality, and safety gate. Use this to confirm intents are landing on native controls and that risky actions keep their confirmation gate.

A provider may accept a send and disconnect before confirming it. ClawUX does not retry that ambiguous operation because doing so could send the message twice. Check the provider, enter an operator label for the audit record, and resolve it explicitly. Message content and recipients are not retained in this operational view.

How the UI composer is deciding and how users respond, aggregated from the same delivery history: decision mix, tap-through by primitive, derived vs backend tap rate, stale taps, per-channel fallback and block rates, and composer latency. Refresh above reloads both views.

Render one backend intent across every channel capability profile without sending live messages. Provider settings or recipient device OS/version can still affect final delivery.

Telegram and RCS attempt live delivery when channel credentials and routing are configured. WhatsApp stays preview only in this console.