Channels

Web UI → Channels shows the messaging platforms each agent bridges — one card per agent profile × platform. It reads /api/channels, which enumerates every profile under ~/.aios/agents (plus the default profile) and checks each one’s .env for a bot token.

What each card shows

• Platform — Telegram, Discord, or Slack (the only three the backend knows about today), with the agent profile name it belongs to.
• State — NOT CONFIGURED (no token), DISABLED (token present but commented out), ENABLED · GATEWAY DOWN, or CONNECTED.
• Identity — for Telegram, the live @username from a real Bot API getMe call against the stored token (proof the token actually works, not just that a string is present).
• Mode — always polling. AIOS gateways long-poll each platform; there is no inbound webhook endpoint (see Webhooks).
• Allowed users, sessions, messages, last active — allowlist size from TELEGRAM_ALLOWED_USER, and activity counts read straight from that profile’s own sessions.db.

The default profile always shows all three platforms, configured or not, so there’s somewhere to set one up. Named profiles only show platforms they’ve already configured — a fleet of Telegram-only agents doesn’t need two empty Discord/Slack cards apiece.

Managing a bot

Each card has:

• Token field + SAVE — writes the platform’s token into that profile’s .env (TELEGRAM_BOT_TOKEN, DISCORD_BOT_TOKEN, or SLACK_BOT_TOKEN), chmod 600, never echoed back to the browser.
• TEST — calls getMe (Telegram) or otherwise confirms the token is set.
• DISABLE / ENABLE — comments/uncomments the token line rather than deleting it, so re-enabling doesn’t require re-pasting the token.
• RESTART — restarts that profile’s gateway unit (aios-gateway.service for default, aios-gateway@<name>.service for a named agent) so the change takes effect.

Each agent’s bot is otherwise identical to the CLI-era setup described in Agents → Talking to an agent: set the token, systemctl enable --now the profile’s gateway unit, done.