QA Channel Plugin for Automated OpenClaw Testing
This page covers the QA channel, a synthetic Slack-class transport for deterministic OpenClaw QA scenarios. It is intended for developers and QA engineers working with automated testing of channel plugin boundaries.
Read this when
- You are wiring the synthetic QA transport into a local or CI test run
- You need the bundled qa-channel config surface
- You are iterating on end-to-end QA automation
qa-channel is a repo-local synthetic message transport used for automated OpenClaw QA (extensions/qa-channel, a private package excluded from packaged installs). It is not meant for production. Its purpose is to exercise the same channel plugin boundary that real transports use, while keeping state deterministic and fully inspectable.
What it does
- Slack-class target grammar:
dm:<user>channel:<room>group:<room>thread:<room>/<thread>
- Shared
channel:andgroup:conversations appear to agents as group or channel room turns. This exercises the same visible-reply and message-tool routing policy used by Discord, Slack, Telegram, and similar transports. - An HTTP-backed synthetic bus handles inbound message injection, outbound transcript capture, thread creation, reactions, edits, deletes, and search or read actions.
- A host-side self-check runner writes a Markdown report to
.artifacts/qa-e2e/.
Config
{
"channels": {
"qa-channel": {
"baseUrl": "http://127.0.0.1:43123",
"botUserId": "openclaw",
"botDisplayName": "OpenClaw QA",
"allowFrom": ["*"],
"pollTimeoutMs": 1000
}
}
}
Account keys:
enabled: master toggle for this account.name: optional display label.baseUrl: synthetic bus URL. The account is considered configured once this is set.botUserId: synthetic bot user id used in target grammar (default:openclaw).botDisplayName: display name for outbound messages (default:OpenClaw QA).pollTimeoutMs: long-poll wait window. Must be an integer between 100 and 30000 (default: 1000).allowFrom: sender allowlist (user ids or"*"; default:["*"]). DMs always followopenpolicy. Allowlisted group policy also uses these synthetic sender ids.groupPolicy: shared-room policy:"open"(default),"allowlist", or"disabled".groupAllowFrom: optional shared-room sender allowlist. When omitted under"allowlist", QA Channel falls back toallowFrom.groups.<room>.requireMention: require a bot mention before replying in a specific group or channel room (default: false).groups."*"sets the default. Per-roomtoolsandtoolsBySenderset tool policy overrides.defaultTo: fallback target when none is supplied.actions.messages,actions.reactions,actions.search,actions.threads: per-action tool gating.
Multi-account keys at the top level:
accounts: record of named per-account overrides keyed by account id.defaultAccount: preferred account id when multiple are configured.
Runners
Host-side self-check (writes a Markdown report under .artifacts/qa-e2e/):
pnpm qa:e2e
This routes through qa-lab, starts the in-repo QA bus, boots the qa-channel runtime slice, and runs a deterministic self-check.
Full repo-backed scenario suite:
pnpm openclaw qa suite
Runs scenarios in parallel against the QA gateway lane. See QA overview for scenarios, profiles, and provider modes.
Docker-backed QA site (gateway and QA Lab debugger UI in one stack):
pnpm qa:lab:up
Builds the QA site, starts the Docker-backed gateway and QA Lab stack, and prints the QA Lab URL. From there you can pick scenarios, choose the model lane, launch individual runs, and watch results live. The QA Lab debugger is separate from the shipped Control UI bundle.
Related
- QA overview covers the overall stack, transport adapters, Matrix profiles, and scenario authoring
- Pairing
- Groups
- Channels overview