Messaging status in Desktop and the dashboard
Messaging status belongs to the selected profile on the selected machine. Credentials saved bymibyan gateway setup can enable a credential-based platform without a
platforms entry in config.yaml; an explicit platforms.<name>.enabled: false
still disables it. A different profile never inherits the server process’s credentials.
Platforms without required credential fields are not enabled merely because that list
is empty.
Naming the server’s own profile explicitly (for example profile=default on a
default-profile server) gives the same status as an unscoped request. Saved means
credentials are stored, not that the messaging gateway is running or the platform is
connected. An enabled platform can correctly show Messaging gateway stopped.
Platform Comparison
Voice = TTS audio replies and/or voice message transcription. Images = send/receive images. Files = send/receive file attachments. Threads = threaded conversations. Reactions = emoji reactions on messages. Typing = typing indicator while processing. Streaming = progressive message updates via editing.
Mibyan RelayMibyan Relay (experimental) is not a chat platform itself — it is a connector system that fronts platforms like Discord, Telegram, Slack, and WhatsApp through an external connector that owns the platform credentials. Capabilities (media, native approval/clarify prompts, reactions, threads, typing, streaming) are negotiated per connector at handshake rather than fixed in the table above.
Architecture
Each platform adapter receives messages, routes them through a per-chat session store, and dispatches them to the AIAgent for processing. The gateway also runs the cron scheduler, ticking every 60 seconds to execute any due jobs.Intentional Silence Tokens
For group chats, hooks, and automation flows, Mibyan supports explicit silence tokens. If the agent’s final response is exactly one supported token, the gateway suppresses outbound delivery and sends nothing to the chat. Supported tokens:[SILENT]SILENTNO_REPLYNO REPLY[静默]/静默and[沉默]/沉默— the Chinese renderings a model produces when it translates the sentinel instead of emitting it literally
[SILENT] when nothing changed” is delivered normally.
Silence is a delivery decision only. Mibyan keeps the assistant silence turn in the session transcript, so the conversation still alternates normally:
Quick Setup
The easiest way to configure messaging platforms is the interactive wizard:Gateway Commands
Stack dump on demand (SIGUSR2)
On Linux and macOS, kill -USR2 <gateway pid> appends a dump of every thread’s
stack to ~/.mibyan/logs/gateway_faulthandler.log and the gateway keeps
running — use it to see what a stalled or misbehaving gateway is doing without
restarting it.
Built-in event-loop liveness watchdog
On every platform the gateway runs an out-of-loop watchdog thread that probes the asyncio loop (gateway.loop_watchdog_probe_interval_s, default 30 s). When
the loop stops dispatching for gateway.loop_watchdog_max_strikes consecutive
probes (default 3), housekeeping, the cron scheduler and the embedded kanban
dispatcher have all frozen with it, so the watchdog dumps every thread’s stack
to the log, stamps gateway_state.json with gateway_state: degraded and
exit_reason: loop_liveness_watchdog, and exits with code 75 so the service
supervisor restarts the process. mibyan gateway status renders that record as
⚠ Gateway exited degraded: event loop stopped dispatching … until a new
gateway process overwrites it, and the dashboard’s gateway badge shows
Degraded with the same reason. Set gateway.loop_watchdog: false in
config.yaml to disable the watchdog.
Housekeeping also re-stamps gateway_state.json’s updated_at every tick
(60 s), so it doubles as a heartbeat: when the process is still alive but that
stamp is more than 120 s old, mibyan gateway status prints
⚠ Gateway heartbeat stale: housekeeping has not refreshed gateway_state.json for N s … and the dashboard badge reads Heartbeat stale — the “looks
running but nothing is scheduled” case. Restart the gateway.
Optional Linux event-loop watchdog
A systemd-managed gateway can opt into process recovery when Python’s asyncio event loop stops receiving scheduling time. This covers whole-process stalls that also prevent platform-specific liveness tasks from running:~/.mibyan/config.yaml
Type=notify,
NotifyAccess=main, and the matching WatchdogSec. Mibyan sends heartbeats
only while its event loop is making timely progress; systemd restarts the
process when they stop. The default 0 keeps the existing Type=simple
behavior. This setting is Linux/systemd-only and does not treat an ordinary
platform network disconnect as an event-loop failure.
Chat Commands (Inside Messaging)
Session Management
Session Persistence
Sessions persist across messages until they reset. The agent remembers your conversation context.Finding Past Sessions (/sessions)
/sessions lists your previous sessions for the current chat — including the one you’re in now, marked (current) — and /sessions <name> resumes one (shorthand for /resume). When the list grows long, /sessions search <query> (alias find) filters by title or session-id match, ordered by most recently active. Cross-origin listing with /sessions all is admin-only — regular users get a notice explaining the list stayed chat-scoped, and only ever see sessions from their own chat origin.
Persistent /model Overrides
A /model switch in a gateway chat applies to that session and now survives gateway restarts: the model/provider choice is persisted to the session store and rehydrated on first use after a restart (credentials are re-resolved at load time and never written to disk). /new (or /reset) clears the override, and /model <name> --global writes it through to config.yaml instead. /model <name> --once applies for a single turn only.
Delivery Reliability
Final agent responses are recorded in a durable delivery ledger (state.db) around each platform send. If the gateway crashes or restarts
between producing a response and the platform confirming receipt, the next
boot redelivers the stored response instead of losing it — or re-running the
whole turn. The ledger lives in the home the gateway was started from; a
multiplexed gateway keeps every served profile’s replies there too.
Semantics are honest at-least-once:
- A response whose send never started is redelivered as-is.
- A response that was mid-send when the gateway died (the platform may or may not have received it), including a redelivery an earlier boot was still sending, is redelivered with a visible “♻️ Recovered reply — … may be a duplicate” prefix. Ambiguity is labeled, never silently resent.
- A final send refused by flood control (such as Telegram rate limits) is retried automatically after the recorded penalty expires, without requiring a reconnect or restart. A restart during the penalty adopts the stored reply without spending a retry attempt or re-running the agent. Retries retain the original bot profile, chat and thread. A rate-limit recovery prefix warns that earlier chunks may already have arrived; the ledger cannot infer partial delivery from message length.
- Any other rejected final send (a platform 5xx, an unclassified error) is retried the same way after a growing backoff (30 s, then 2 min); the last budgeted attempt is left for the next gateway start, so an outage that outlasts the timer never strands the reply. A permanently unreachable chat (blocked bot, deleted group) is not retried.
- Redelivery is bounded: 3 attempts, 24-hour freshness, then the row is abandoned. Delivered rows are pruned after 7 days.
gateway.delivery_ledger: false in config.yaml (restores the
old behavior: in-flight responses are lost on crash).
Session continuity
Gateway conversations do not reset after inactivity or at a daily boundary. Use/new
or /reset for an explicit new conversation; context compression remains automatic.
Core ignores legacy session_reset settings, reset-policy overrides and reset-timer
environment variables. If your config still sets session_reset.mode to idle, daily
or both, gateway startup and mibyan doctor warn about it. To keep time-based resets,
install the catalog plugin that reads the same block unchanged:
mibyan plugins install mibyan-session-reset-policy. Cached agents may be released to reclaim resources without
replacing the durable conversation. Restart-recovery freshness limits automatic
continuation, not the history loaded when you send a message.
Per-Channel Model & System Prompt Overrides
Different channels can run different models and personas from a single gateway — e.g. a cheap fast model in#daily and a frontier model with a specialist prompt in #dev. Configure channel_overrides under the platform in ~/.mibyan/config.yaml:
- All three keys are optional — set only
model, onlysystem_prompt, or any combination. Unset fields fall back to the global defaults. - Lookup order is exact channel/thread id first, then the parent channel/forum id — so Discord threads inherit their parent channel’s override automatically.
- Resolution priority for the model is: session
/modeloverride →channel_overrides→ global config. A user running/modelin a chat still wins over the channel default. - The
system_promptoverride replaces the global gateway prompt for that channel (it is ephemeral — injected per turn, not stored in history).
Security
By default, the gateway denies all users who are not in an allowlist or paired via DM. This is the safe default for a bot with terminal access.DM Pairing (Alternative to Allowlists)
Instead of manually configuring user IDs, unknown users receive a one-time pairing code when they DM the bot. Email is the exception: unknown email senders are ignored unless email pairing is explicitly enabled.Admins vs Regular Users
Allowlists answer “can this person reach the bot at all?” The admin / user split answers “now that they’re in, what are they allowed to do?” Every allowed user falls into one of two tiers per scope (DM vs group/channel):- Admin — full access. Can run every registered slash command (built-in + plugin) and use every gated capability.
- Regular user — restricted access. Can chat with the agent normally, but can only run the slash commands you explicitly enable. The always-allowed floor is
/helpand/whoami.
Configuration
allow_admin_from is not set for a scope, the tier split is disabled for that scope and every allowed user has full access. Existing installs keep working with no changes — opt in when you want the distinction.
Inspecting your access
Use/whoami from any platform to see the active scope, your tier (admin / user / unrestricted), and which slash commands you can run. When an admin list is configured, /help and /commands show a non-admin only the commands they can actually run (/help, /whoami, plus user_allowed_commands); admins see the full catalog. See the Telegram and Discord pages for platform-specific examples.
Redirecting the Agent
Send a message while the agent is working to correct the active turn:- Model generation restarts with context — reasoning already shown and visible partial text are retained as an ordinary assistant checkpoint
- Completed work stays available — prior tool calls and results remain in the turn
- Running tools finish safely — the correction is applied at the next tool-result boundary instead of killing the tool
/stopremains a hard stop — use it to cancel the active turn and foreground work
Queue vs interrupt vs steer (busy-input mode)
By default, messaging a busy agent redirects its active turn (a running foreground terminal command is moved to the background rather than killed, so your message is read immediately). Two other modes are available:queue— follow-up messages wait and run as the next turn after the current task finishes. Each follow-up (text, voice note, video, document) gets its own turn in arrival order; only a rapid photo burst is merged into one album turn.steer— follow-up messages are injected into the current run via/steer, arriving at the agent after the next tool call. No interrupt, no new turn. Falls back toqueuebehavior if the agent hasn’t started yet.
/steer) and active-turn redirects carry the requesting event’s available platform, chat, thread, sender, message, profile, and scope identifiers as per-message JSON context. With privacy.redact_pii: true, identifiers in this model-visible context are hashed on supported platforms, including alternate and parent identifiers; the original event identifiers remain internal for routing. Otherwise identifiers are preserved exactly. Neither mode changes the session’s system prompt or chooses a fallback reply destination. The context is routing data, not authorization or a guarantee of automatic delivery.
config.yaml, so multiplexed profiles keep independent busy policies; there is no process-environment override.
The first time you message a busy agent on any platform, Mibyan appends a one-line reminder to the busy-ack explaining the knob ("💡 First-time tip — …"). The reminder fires once per install — a flag under onboarding.seen.busy_input_prompt latches it. Delete that key to see the tip again.
If you find the busy acknowledgment noisy, set display.busy_ack_enabled: false. Input handling is unchanged; only the confirmation message is hidden.
Clarify Questions (Multi-Select)
When the agent uses theclarify tool to ask you a question, the gateway renders the choices as a numbered prompt (or native buttons on platforms that support them). Clarify supports multi-select questions too — the agent can let you pick several options at once:
- Messaging platforms — the prompt says “Multiple selections allowed”; reply with the numbers separated by commas or spaces (e.g.
1, 3), the option text, or your own free-form answer. - Classic CLI / TUI — multi-select renders as checkboxes: Space toggles an option, Enter submits the selection.
Tool Progress Notifications
Control how much tool activity is displayed in~/.mibyan/config.yaml:
log mode — audit file instead of chat messages
Setting display.tool_progress: log sends no progress bubbles to chat. Instead, each tool call is appended as a line to ~/.mibyan/logs/tool_calls.log — a rotating audit file (5 MB × 3 backups) run through the same secret-redacting formatter as regular logs, so credentials never land on disk. Use it when you want a full tool-call trail without any chat noise.
Configurable status phrases
Long-running gateway status lines (“still working…”-style heartbeats) draw from a phrase catalog. Built-in defaults ship ingateway/assets/status_phrases.yaml; you can add your own with profile-portable files under mibyan_HOME:
~/.mibyan/status_phrases.yamlor any*.yamlin~/.mibyan/status_phrases/(conventional paths, auto-loaded), or- point config at a relative path:
status, generic) to a list of strings (max 80 phrases per surface, 160 chars each). Absolute paths and .. escapes are ignored so config stays profile-portable. Only your configured phrase strings are used — raw tool arguments, commands, and reasoning text are never interpolated into a status phrase.
Message timestamps in model context
Off by default. When enabled, Mibyan prepends a human-readable timestamp (e.g.[Tue 2026-04-28 13:40:53 CEST]) onto each user message in the
model’s context so the agent knows when messages were sent — useful for
temporal reasoning (“you asked this morning…”, noticing a long gap). It is
not added to assistant messages or the system prompt.
Background Sessions
Run a prompt in a separate background session so the agent works on it independently while your main chat stays responsive:How It Works
Each/bg prompt spawns a separate agent instance that runs asynchronously:
- Isolated session — the background agent has its own session with its own conversation history. It has no knowledge of your current chat context and receives only the prompt you provide.
- Same configuration — inherits your model, provider, toolsets, reasoning settings, and provider routing from the current gateway setup.
- Non-blocking — your main chat stays fully interactive. Send messages, run other commands, or start more background tasks while it works.
- Result delivery — when the task finishes, the result is sent back to the same chat or channel where you issued the command, prefixed with ”✅ Background task complete”. If it fails, you’ll see ”❌ Background task failed” with the error.
Background Process Notifications
When the agent running a background session usesterminal(background=true) to start long-running processes (servers, builds, etc.), the gateway can push status updates to your chat. Control this with display.background_process_notifications in ~/.mibyan/config.yaml:
You can also set this via environment variable:
terminal(background=true, notify_on_complete=true) the finished process starts a new agent turn and the agent reports the result itself, so no separate status line is sent. The exception is a process that finishes while the turn that launched it is still running: the completion is queued as the agent’s next turn and you get the one-line concise status right away (unless the mode is off, or error with a zero exit code), instead of silence until that turn ends.
Use Cases
- Server monitoring — “/bg Check the health of all services and alert me if anything is down”
- Long builds — “/bg Build and deploy the staging environment” while you continue chatting
- Research tasks — “/bg Research competitor pricing and summarize in a table”
- File operations — “/bg Organize the photos in ~/Downloads by date into folders”
Service Management
Linux (systemd)
Direct systemctl restart / stop exits cleanly
The installed unit declares ExecStop= to record a planned-stop marker for $MAINPID before SIGTERM is delivered, so stopping or restarting the service directly is classified as intentional: the gateway drains, persists gateway_state=stopped, and exits 0 — the journal shows a clean stop/start with no Failed with result exit-code line.
mibyan gateway restart when in-flight agent turns matter: it asks the gateway to drain first (SIGUSR1, honoring the restart wait budget) and waits for the replacement, while a raw systemctl restart stops the current process on systemd’s schedule. After updating Mibyan, run mibyan gateway restart once so the running service picks up the regenerated unit that contains the ExecStop= line (mibyan gateway status warns while the installed unit is outdated).
The installed unit also maps systemctl reload mibyan-gateway to SIGUSR1. For Mibyan, reload therefore means a graceful drain, process exit, and supervisor relaunch; it is not an in-process configuration reload. Use mibyan gateway restart when you want the CLI to wait for and verify the replacement process.
Avoid keeping both the user and system gateway units installed at once unless you really mean to. Mibyan will warn if it detects both because start/stop/status behavior gets ambiguous.
Inside a container, only the system scope is offered
mibyan gateway install (and the mibyan gateway setup wizard) refuse to install a user service when Mibyan detects it is running inside a container. A user unit lands in ~/.config/systemd/user, and when that home is bind-mounted from the host (podman/distrobox), the host’s own systemd --user enables and starts the same unit — a second gateway polling the same bot token. Run the gateway as the container’s main process (mibyan gateway run, with a container restart policy), or in a systemd container (systemd as PID 1) install the isolated system scope: sudo mibyan gateway install --system --run-as-user <user>.Multiple installationsIf you run multiple Mibyan installations on the same machine (with different
mibyan_HOME directories), each gets its own systemd service name. The default ~/.mibyan uses mibyan-gateway; other installations use mibyan-gateway-<hash>. The mibyan gateway commands automatically target the correct service for your current mibyan_HOME.macOS (launchd)
~/Library/LaunchAgents/ai.mibyan.gateway.plist. It includes three environment variables:
- PATH — your full shell PATH at install time, with the venv
bin/andnode_modules/.binprepended. This ensures user-installed tools (Node.js, ffmpeg, etc.) are available to gateway subprocesses like the WhatsApp bridge. - VIRTUAL_ENV — points to the Python virtualenv so tools can resolve packages correctly.
- mibyan_HOME — scopes the gateway to your Mibyan installation.
Installing without startingThe plist sets
RunAtLoad, so loading it starts the gateway. mibyan gateway install --no-start-now, like answering No to “Start the gateway now?” in mibyan gateway setup, writes the plist without loading it: the gateway starts at your next login, or when you run mibyan gateway start. A gateway that launchd is already running is reloaded onto the new plist, not stopped.Local Network access (LAN devices fail with “No route to host”)macOS Local Network Privacy attributes a socket to the executable launchd spawned for the job. A bare venv Python has no application identity, so a launchd-run gateway could not reach LAN hosts (Home Assistant, local model servers) — every connect failed with
errno 65 No route to host while the same URL worked from Terminal, and no prompt was ever shown to grant it. The generated plist therefore runs the gateway through /usr/bin/osascript; a JXA system() call starts the gateway without an interactive event-polling loop, and macOS treats its children as osascript’s own — an Apple platform binary, exempt from the check. ps shows osascript → stderr_timestamp → gateway run; stop/restart/KeepAlive behave exactly as before. A plist installed by an older Mibyan is refreshed by mibyan gateway install (or on the next mibyan gateway start).Multiple installationsLike the Linux systemd service, each
mibyan_HOME directory gets its own launchd label. The default ~/.mibyan uses ai.mibyan.gateway; other installations use ai.mibyan.gateway-<suffix>.Windows (Task Scheduler)
wscript.exe on a generated .vbs launcher under %USERPROFILE%\.mibyan\gateway-service\. The launcher starts python.exe -m mibyan_cli.main gateway run with a hidden window and exits immediately — by design: wscript.exe has no console, so at logon it never receives the CTRL_CLOSE_EVENT that kills a cmd.exe-hosted gateway, and the gateway inherits one hidden console instead of every subprocess flashing its own (see mibyan_cli/gateway_windows.py::_build_gateway_vbs_script).
mibyan gateway install writes the task from the current template; a task registered by an older build would otherwise keep its old settings (no RestartOnFailure, no logon Delay, an older launcher command line) indefinitely. mibyan gateway status compares the registered task with the current template and warns when it predates it:
mibyan gateway start and mibyan update run the same comparison and re-register a drifted task from the current template automatically (like the systemd unit refresh on Linux); when schtasks refuses without elevation, re-run mibyan gateway install, which can request administrator approval. The check is silent when the task cannot be queried, and it only inspects a few settings Mibyan owns (task version, RestartOnFailure, the logon trigger delay and the launcher arguments), so deliberate local edits elsewhere in the task are not flagged.
Platform-Specific Toolsets
Each platform has its own toolset:Operating a multi-platform gateway
A gateway typically runs several adapters at once (Telegram + Discord + Slack, etc.). The sections below cover day-2 operations that span all platforms./platform command
Once the gateway is running, use the /platform slash command from any connected CLI session or chat to inspect and steer individual adapters without restarting the whole gateway:
/platform list shows whether each adapter is running, paused (manually), or paused-by-breaker (see below). Pausing keeps the adapter loaded and its background loops alive — incoming messages are dropped on the floor, but the connection itself stays open so resume is instant.
See also the broader status summary command /platforms.
Disabling a platform whose credentials are still in .env
platforms.<name>.enabled: false in ~/.mibyan/config.yaml is authoritative.
Credentials for that platform left in the environment (TELEGRAM_BOT_TOKEN,
WEIXIN_TOKEN, HASS_TOKEN, EMAIL_*, TWILIO_ACCOUNT_SID, …) are still
wired into the platform’s config so send-only tooling keeps working, but they
no longer start the adapter:
~/.mibyan/config.yaml
enabled key entirely keeps the env-only behaviour: credentials
present → adapter starts.
Ignoring an inherited proxy (gateway.trust_env)
By default every platform adapter honors HTTP_PROXY / HTTPS_PROXY /
NO_PROXY (and SSL_CERT_FILE) from the gateway’s environment, and
auto-detects the macOS system proxy. A gateway started by a Windows Scheduled
Task or a service manager can inherit a proxy the interactive shell never
sees — a local Clash/V2Ray listener that isn’t running yet — and log
Cannot connect to host 127.0.0.1:7890 on every poll. Turn the inherited
proxy off for all adapters at once:
~/.mibyan/config.yaml
DISCORD_PROXY, TELEGRAM_PROXY,
MATRIX_PROXY, …) are still honored. Restart the gateway after changing it.
Automatic circuit breaker
Each adapter is wrapped in a circuit breaker. Repeated retryable failures (network blips, rate-limit replies, 5xx upstream responses, websocket disconnects) cause the breaker to trip — the adapter is auto-paused, an operator notification is sent to the home channel of another live platform when one is configured, and a structured log line is emitted. The breaker does not auto-resume — it stays open until you run/platform resume <name> manually. This is intentional: if a platform is in a sustained outage, you don’t want the gateway thrashing reconnects.
Where to look when a platform is paused
When an adapter is paused, check:- Gateway log (
~/.mibyan/logs/gateway.logor the systemd / launchd unit log). Search for the platform name andcircuit breaker,paused, ordisabled. The trip event includes the failure count and the last error. /platform listoutput — shows the current state and last reason.- The provider’s status page (Telegram bot API status, Discord status, etc.). The breaker tripped because the platform was unhealthy; don’t try to resume until it’s back.
/platform resume <name> clears the breaker and re-arms the adapter.
Restart notifications
When the gateway restarts (or is shut down with in-flight sessions), it can send a one-shot “the agent is back” / “the agent was interrupted” message to each platform’s home channel. This is controlled per-platform by thegateway_restart_notification flag in config.yaml, which defaults to true:
Typing indicators
While the agent is processing a message, the gateway shows a live typing status on platforms that support it — a “typing…” bubble on Telegram/Discord/Signal, or the “is thinking…” assistant status on Slack. This is controlled per-platform by thetyping_indicator flag in config.yaml, which defaults to true:
typing_indicator: false on any platform where the indicator is unwanted. Some users find Slack’s “is thinking…” status noisy (it also briefly disables the compose box while shown, since it uses Slack’s Assistant API). Disabling it only suppresses the indicator — message delivery and everything else is unchanged. The flag is generic, so the same key works for every platform.
Session resume across gateway restarts
When the gateway shuts down with an in-flight tool call or generation, the affected sessions are flagged asrestart_interrupted. On the next startup, the gateway schedules an auto-resume for each one — the user gets a short heads-up in the chat (“Send any message after restart and I’ll try to resume where you left off.”) and the session picks up from the last committed turn when they reply.
Only turns that were actually in flight are resumed, and each resumes once. A chat whose turn had already finished is never answered again just because it was active shortly before a crash. If the gateway was killed after the agent finished a reply but before it was sent, the stored reply is delivered (with a “Recovered reply” notice) instead of being regenerated.
This behaviour is on by default and is logged at gateway start:
gateway_restart_notification: false on the platform.
Mobile-friendly progress defaults
Telegram is usually a mobile inbox, so the defaults are tuned for that surface:tool_progressdefaults tooff— no per-tool breadcrumb stream filling up the chat.busy_ack_detaildefaults tooff— busy-state acknowledgments and long-running heartbeats stay terse (noiteration 21/60debug detail).interim_assistant_messagesstays on — real mid-turn assistant commentary (the model literally telling you what it’s about to do) is signal, not noise.long_running_notificationsstays on — a single edit-in-place ”⏳ Working — N min” bubble updates every few minutes so you have a heartbeat instead of staring attyping…for half an hour.
display:. A global display.tool_progress, display.show_reasoning, display.busy_ack_detail, display.interim_assistant_messages or display.long_running_notifications applies to every platform and replaces its default. A config.yaml copied from an older cli-config.yaml.example sets all five globally, and an older first-time mibyan setup wrote tool_progress: all; delete those lines to get the per-platform defaults back.
Opt out of either of the kept-on defaults or opt back into verbose progress per platform:
Warning and error notifications (opt-in suppression)
Automatic warning and error notifications are shown by default. To suppress these notifications, enablesuppress_warning_notifications globally or for
an individual surface:
false to preserve normal delivery. Platform
overrides take precedence; null inherits. Invalid values do not enable
suppression.
The setting controls automatic engine warnings, retry/fallback diagnostics,
watchdog and database notices, cron failure notifications, Kanban failure
notifications, background/delegation diagnostics, and adapter-generated error
notices. It applies to messaging platforms, CLI/TUI presentation and API
notification presentation. Classification belongs to the producer: warning-like
text in a user request or an ordinary result is not filtered by its wording.
Suppression changes presentation, not execution. Existing logs, stored diagnostic
content, retry decisions, failure state, scheduler bookkeeping and notification
cursors remain available. A diagnostic-only internal wake (a subagent or credit
failure, a Kanban crash notice) still runs its agent turn — so the agent can act on
the failure and the session history stays consistent — and that turn is billed as
usual; only its unsolicited text, media and streaming presentation are muted. Structured
approval and clarification controls, direct command/API outcomes and requested
results are not converted into success or discarded. API failure flags, status
codes and usage remain truthful even when diagnostic text is hidden.
Cron failure_deliver still selects the destination; the destination’s warning
policy determines whether an automatic failure notice is presented there.
Suppressed deliveries are settled without claiming a successful send. Already
admitted deliveries retain their delivery identity and outcome.
Policy is resolved for the owning profile and logical destination. Agent turns
use their turn policy; independent notifications and deferred deliveries evaluate
policy at their own delivery boundary. Already delivered messages are not removed.
Suppression does not fix an underlying failure or add another logging destination.
Progress bubble cleanup (opt-in)
Tool-progress messages, the “still working…” heartbeat, and status-callback bubbles can also be auto-deleted after the final response lands. Enable per-platform viadisplay.platforms.<platform>.cleanup_progress:
false. Only platforms whose adapter implements delete_message honor the setting (currently Telegram and Discord). Failed runs skip cleanup so the bubbles remain as breadcrumbs.
Next Steps
- Telegram Setup
- Discord Setup
- Slack Setup
- Google Chat Setup
- WhatsApp Setup
- WhatsApp Business Cloud API Setup
- Signal Setup
- SMS Setup (Twilio)
- Email Setup
- Home Assistant Integration
- Mattermost Setup
- Matrix Setup
- DingTalk Setup
- Feishu/Lark Setup
- WeCom Setup
- WeCom Callback Setup
- Weixin Setup (WeChat)
- BlueBubbles Setup (iMessage)
- Photon Setup (iMessage)
- QQBot Setup
- Yuanbao Setup
- Microsoft Teams Setup
- Teams Meetings Pipeline
- Microsoft Graph Webhook Listener
- LINE Setup
- ntfy Setup
- SimpleX Chat Setup
- Open WebUI + API Server
- Raft Setup
- IRC Setup
- Buzz Setup
- A2A (Agent-to-Agent) Setup
- Webhooks