Admin Console

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 in the Channels tab.

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.

RCS testing runs through the local RCS sender service; these settings belong to the RCS channel above. Use E.164 format.

Choose which AI platform each channel routes to. Secrets stay in environment variables.

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.

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.