[Feature]: Channel Broker Phase 2D Slack opt-in broker routing proof

[100yenadmin]

Maintainer TL;DR

This stack consolidates the recurring Telegram/Discord/Slack/WhatsApp/Signal/iMessage/etc. maintenance churn behind one Channel Broker contract. OpenClaw keeps the shared semantics that repeatedly regress across native channel plugins: sessions, allowlists, routing, /verbose, streaming policy, durable final sends, receipts, retries, and auditability. Broker providers own platform mechanics: bot APIs, bridge/device state, native ids, delivery quirks, and provider capabilities.

This PR proves Slack DMs and channel threads can route through broker-owned semantics while native Slack remains the default path.

The direction is intentionally incremental: first land the versioned broker SDK/plugin foundation, then prove conformance, then prove opt-in routing for the major channels, then model long-tail and constrained providers. Only after migration paths exist should legacy native-channel feature work freeze in #86115.

Why This Is Better

Today, one fix to streaming, /verbose, or delivery behavior can make Telegram fast this week and then break Discord, Slack, or another native plugin the next week. The broker path makes those shared semantics one OpenClaw-owned contract instead of many platform-specific re-implementations. When a provider adds support for previews, threads, receipts, media, or constrained account modes, that capability can become available through the same contract to routed channels whose provider declares and passes conformance for it.

Stack Shape

flowchart TD
  U["Umbrella issue #86105: reduce maintained-channel churn"] --> P1["#86096 Phase 1: SDK + bundled broker foundation"]
  P1 --> P2A["#86153 Phase 2A: conformance + signed inbound"]
  P2A --> P2B["#86154 Phase 2B: Telegram opt-in proof"]
  P2B --> P2C["#86156 Phase 2C: Discord opt-in proof"]
  P2C --> P2D["#86157 Phase 2D: Slack opt-in proof"]
  P2D --> P3["#86164 Phase 3: official/app capability matrix"]
  P3 --> P4["#86165 Phase 4: constrained provider capabilities"]
  P4 -. "future, not in this stack" .-> P5["Future freeze issue #86115: legacy native-plugin freeze"]

Loading

PR	Role in the consolidation
#86096	Creates the versioned broker SDK/plugin foundation, provider routing guard, media final-send mapping, SecretRef/cancellation handling, prefix-ownership contract, and truthful declared-capability boundary.
#86153	Proves shared lifecycle conformance and adds signed inbound webhook registration/runtime handoff: inbound dedupe, explicit listed-provider gating, durable final sends, receipts, retryable failures, payload/live-preview delivery requests, and /verbose channelData.
#86154	Proves Telegram DMs and topics can route through broker targets without native Telegram internals.
#86156	Proves Discord DMs/channels/threads preserve conversation semantics through broker routing.
#86157	Proves Slack DMs/channel threads preserve direct/thread semantics through broker routing.
#86164	Adds official/app and regional platform aliases, inbound alias canonicalization, WeChat/Weixin coverage, capability matrix rows, and declared delivery capability enforcement for long-tail channels.
#86165	Adds closed constrained-provider metadata for WhatsApp, Signal, iMessage, and bridge-backed providers, including BlueBubbles-backed Mac/Messages constraints, without making BlueBubbles a separate platform identity.

Ownership Model

flowchart LR
  Core["OpenClaw core<br/>sessions, routing, allowlists<br/>/verbose, streaming, retries<br/>receipts, audit"] --> Broker["channel-broker plugin<br/>openclaw/plugin-sdk/channel-broker<br/>V1 protocol"]
  Broker --> Provider["Provider-owned broker<br/>HTTP/webhook transport<br/>platform adapters"]
  Provider --> Platforms["Telegram, Discord, Slack<br/>Teams, Matrix, WhatsApp<br/>Signal, iMessage, long tail"]
  Provider --> Broker
  Broker --> Core

Loading

Review Shape

These PRs are intentionally linear. GitHub still shows main as the base for each PR so maintainers can land them one by one from fork branches; the branches themselves are stacked, and maintainers can review the focused adjacent diffs here:

PR	Focused adjacent diff
#86153	100yenadmin/openclaw@feat/channel-broker-protocol...feat/channel-broker-conformance
#86154	100yenadmin/openclaw@feat/channel-broker-conformance...feat/channel-broker-telegram-routing
#86156	100yenadmin/openclaw@feat/channel-broker-telegram-routing...feat/channel-broker-discord-routing
#86157	100yenadmin/openclaw@feat/channel-broker-discord-routing...feat/channel-broker-slack-routing
#86164	100yenadmin/openclaw@feat/channel-broker-slack-routing...feat/channel-broker-official-platform-capabilities
#86165	100yenadmin/openclaw@feat/channel-broker-official-platform-capabilities...feat/channel-broker-constrained-platform-capabilities

This PR

• Phase: Phase 2D - Slack opt-in broker routing proof
• Role: Proves Slack DMs/channel threads preserve direct/thread semantics through broker routing.
• Head: 7614f3bcfb

Current Review State

This PR is live for maintainer review. Current head: 7614f3bcfb

This branch also carries the tiny src/agents/model-catalog-visibility.test.ts timeout hardening inherited from #86096 after the unrelated checks-node-agentic-agents shard repeatedly timed out there while the single file passed locally.

Focused local validation after the latest package/deadcode/doc/capability repair and upstream/main rebase ran from /Volumes/LEXAR/repos/openclaw-channel-broker:

• git diff --check upstream/main..HEAD
• pnpm exec vitest run src/plugin-sdk/channel-broker.test.ts --config test/vitest/vitest.unit-fast.config.ts --maxWorkers=1
• pnpm exec vitest run extensions/channel-broker/src/channel.test.ts extensions/channel-broker/src/config-schema.test.ts extensions/channel-broker/src/conformance.test.ts extensions/channel-broker/src/http-routes.test.ts --config test/vitest/vitest.extension-channel-broker.config.ts --maxWorkers=1
• pnpm exec vitest run src/plugins/contracts/plugin-sdk-package-contract-guardrails.test.ts --config test/vitest/vitest.contracts-plugin.config.ts --maxWorkers=1
• pnpm exec vitest run test/scripts/bundled-plugin-build-entries.test.ts --config test/vitest/vitest.tooling.config.ts --maxWorkers=1
• pnpm exec vitest run test/scripts/check-deadcode-unused-files.test.ts --config test/vitest/vitest.unit-fast.config.ts --maxWorkers=1
• node scripts/check-deadcode-unused-files.mjs
• pnpm exec tsc -p extensions/channel-broker/tsconfig.json --noEmit

Broad validation remains owned by GitHub Actions.

Summary

• Adds the Phase 2D Slack migration proof for the Channel Broker rollout.
• Keeps native Slack default behavior unchanged; this only proves opt-in broker routing for Slack targets.
• Stacks on Phase 2C Discord proof ([Feature]: Channel Broker Phase 2C Discord opt-in broker routing proof #86156), Phase 2B Telegram proof ([Feature]: Channel Broker Phase 2B Telegram opt-in broker routing proof #86154), Phase 2A conformance baseline ([Feature]: Channel Broker Phase 2A conformance harness #86153), and Phase 1 broker foundation ([Feature]: Channel Broker Phase 1 protocol foundation #86096).

Closes #86112
Related #86108
Related #86105
Supersedes closed PR #86142, which was closed by the repository active-PR cap rather than by an implementation failure.

What changed

• Normalize broker-prefixed Slack DM targets such as broker:slack:user:U12345678 into broker provider requests with conversation.type = "direct".
• Normalize broker-prefixed Slack channel thread targets such as broker:slack:channel:C12345678?threadId=1716500000.000001 into broker provider requests with conversation.type = "channel" and threadId.
• Canonicalize Slack broker session routes to the resolved platform target, preserving direct-route semantics as slack:direct%3A<user> and thread routes as slack:<channel>?threadId=<threadTs>.

Real Behavior Proof

• Behavior or issue addressed: Slack DM and threaded-channel targets can route through channel-broker while preserving direct/channel conversation semantics and Slack threadTs as broker threadId.
• Real environment tested: Local OpenClaw checkout at /Volumes/LEXAR/repos/openclaw-channel-broker, using the Channel Broker plugin and SDK from the stacked rollout branch on May 24, 2026.
• Exact steps or command run after this patch: Ran a node --import tsx --input-type=module terminal proof that called channelBrokerPlugin.message.send.text with to: "broker:slack:channel:C12345678?threadId=1716500000.000001" and captured the provider request passed to the configured broker runtime.
• Evidence after fix: Terminal output excerpt from that local command:

{
  "label": "slack-thread",
  "messageId": "native-slack-thread",
  "platform": "slack",
  "conversation": {
    "id": "C12345678",
    "type": "channel",
    "threadId": "1716500000.000001"
  },
  "requirements": {
    "text": true,
    "thread": true
  }
}

• Observed result after fix: The live plugin path produced the expected Slack provider request and kept threaded delivery represented by the broker threadId field.
• What was not tested: Live Slack API traffic and the full local suite; this PR stays scoped to opt-in broker routing proof.

Focused diff for this stack layer:

100yenadmin/openclaw@feat/channel-broker-discord-routing...feat/channel-broker-slack-routing

Validation

Run locally from /Volumes/LEXAR/repos/openclaw-channel-broker:

• pnpm exec vitest run extensions/channel-broker/src/channel.test.ts extensions/channel-broker/src/conformance.test.ts --config test/vitest/vitest.extension-channel-broker.config.ts
• pnpm exec tsc --noEmit -p extensions/channel-broker/tsconfig.json
• git diff --check
• pnpm exec oxfmt --check extensions/channel-broker/src/target.ts extensions/channel-broker/src/channel.ts extensions/channel-broker/src/channel.test.ts
• pnpm exec oxlint extensions/channel-broker --format unix

Review state

• Live for maintainer review; no longer draft.
• No native Slack migration is enabled by default in this PR.

[clawsweeper]

Codex review: needs real behavior proof before merge. Reviewed May 27, 2026, 7:38 AM ET / 11:38 UTC.

Summary
The PR adds a bundled channel-broker plugin plus public SDK, docs, config, tests, signed inbound routing, and opt-in Slack DM/thread broker target normalization while keeping native Slack as the default path.

PR surface: Source +3430, Tests +4694, Docs +306, Config +77, Generated 0, Other +22. Total +8529 across 57 files.

Reproducibility: yes. for the review finding: source inspection shows accessGroup allowFrom entries return true at the HTTP gate before sender membership is checked. I did not run a live webhook because this review is read-only.

Review metrics: 2 noteworthy metrics.

• New config and credential surfaces: 1 channel schema and 6 SecretRef paths added. These paths affect setup, credential resolution, docs, and upgrade safety for any user who opts into the broker.
• Public broker surfaces: 1 SDK subpath, 1 bundled channel, 1 signed inbound route added. This is a new plugin-facing contract plus a new authenticated network entrypoint, not only Slack routing proof.

Merge readiness
Overall: 🧂 unranked krab
Proof: 🦪 silver shellfish
Patch quality: 🧂 unranked krab
Result: blocked until stronger real behavior proof is added.

Overall follows the weaker of proof and patch quality, so missing proof can cap an otherwise strong patch.

Rank-up moves:

• Fix access-group admission and add a regression covering an unmatched accessGroup sender being rejected before runtime dispatch.
• Update the PR body with current-head Slack broker routing proof and redact private details.
• Wait for maintainer approval of the public SDK/config/security rollout before landing the stack.

Proof guidance:
Needs stronger real behavior proof before merge: The PR body includes terminal proof, but it is tied to an older head while the live head is e171199; the contributor should add current-head terminal or live output with private details redacted, then update the PR body for automatic re-review.

Risk before merge

• Signed inbound webhooks with allowFrom access-group entries can pass the HTTP admission gate without matching the sender to the group, which is a security-boundary problem if a custom broker runtime handles the event before the standard ingress resolver blocks it.
• The PR body's real behavior proof is tied to an older head, while the live head has additional Slack routing and stack repair commits.
• The branch adds public SDK, bundled plugin, config, SecretRef, signed HTTP route, and channel-prefix behavior, so maintainers need an explicit compatibility and rollout decision before merge.
• The PR is part of an open stacked broker rollout; landing this branch effectively lands foundation and conformance surfaces that are still under review in predecessor PRs.

Maintainer options:

1. Fix admission and refresh proof first (recommended)
   Resolve access-group membership before the signed webhook gate accepts an event, add a denial regression test, and update the PR body with current-head terminal or live output.
2. Accept the broker contract as maintainer-owned
   Maintainers can intentionally accept the new SDK/config/security surface only after reviewing the stacked rollout and recording upgrade expectations.
3. Pause behind the earlier broker phases
   If the foundation or conformance PRs are not ready, pause or close this phase until those public contracts are settled.

Next step before merge
Human maintainer handling is needed because the PR adds public SDK/config/security surfaces and needs contributor-supplied current-head proof; automation cannot supply that proof or decide the broker contract rollout.

Security
Needs attention: The signed inbound webhook admission path has a concrete access-group authorization flaw that should block merge.

Review findings

• [P1] Resolve access groups before accepting inbound webhooks — extensions/channel-broker/src/http-routes.ts:73-74

Review details

Best possible solution:

Fix broker webhook access-group admission, refresh current-head real behavior proof, and land the broker phases only after maintainers approve the public SDK, config, and security contract.

Do we have a high-confidence way to reproduce the issue?

Yes for the review finding: source inspection shows accessGroup allowFrom entries return true at the HTTP gate before sender membership is checked. I did not run a live webhook because this review is read-only.

Is this the best way to solve the issue?

No, not yet. The broker direction may be useful, but this PR should not merge until the authorization gate is fixed, proof is refreshed for the current head, and maintainers approve the public SDK/config rollout.

Full review comments:

• [P1] Resolve access groups before accepting inbound webhooks — extensions/channel-broker/src/http-routes.ts:73-74
  When allowFrom contains an accessGroup:* entry, this gate returns true without checking whether the broker sender is actually in that group. That lets any signed event for a provider with an access-group allowlist reach receiveBrokerInboundEvent; custom broker runtimes can then process it before the standard ingress resolver has a chance to deny the sender. Resolve the group membership at this gate, or remove this shortcut and fail closed instead of treating group references as wildcard allowlists.
  Confidence: 0.86

Overall correctness: patch is incorrect
Overall confidence: 0.84

AGENTS.md: found and applied where relevant.

Codex review notes: model gpt-5.5, reasoning high; reviewed against 0503853c294b.

Label changes

Label justifications:

• P2: This is a normal-priority but broad opt-in feature with public SDK, config, and channel-routing impact.
• merge-risk: 🚨 compatibility: The diff adds a public SDK subpath, package export, bundled channel, config schema, SecretRef paths, and prefix-routing behavior.
• merge-risk: 🚨 message-delivery: The broker changes how opted-in Slack, Discord, Telegram, and future channel targets map to sessions, threads, and provider requests.
• merge-risk: 🚨 security-boundary: The diff adds signed inbound webhooks and credential handling, and the current admission gate mishandles access-group allowlists.
• rating: 🧂 unranked krab: Overall readiness is 🧂 unranked krab; proof is 🦪 silver shellfish and patch quality is 🧂 unranked krab.
• status: 📣 needs proof: The PR needs real behavior proof before ClawSweeper can clear the contributor ask. Needs stronger real behavior proof before merge: The PR body includes terminal proof, but it is tied to an older head while the live head is e171199; the contributor should add current-head terminal or live output with private details redacted, then update the PR body for automatic re-review.

Evidence reviewed

PR surface:

Source +3430, Tests +4694, Docs +306, Config +77, Generated 0, Other +22. Total +8529 across 57 files.

View PR surface stats

Area	Files	Added	Removed	Net
Source	21	3435	5	+3430
Tests	18	4699	5	+4694
Docs	8	308	2	+306
Config	4	77	0	+77
Generated	2	19	19	0
Other	4	22	0	+22
Total	57	8560	31	+8529

Security concerns:

• [high] Access-group allowlists are treated as webhook admission wildcards — extensions/channel-broker/src/http-routes.ts:73
  The HTTP gate accepts any event when an access-group entry is present, without matching the sender to the group, which can bypass the intended pre-dispatch authorization boundary for custom broker runtimes.
  Confidence: 0.86

What I checked:

• Root and scoped policy read: Read the full root AGENTS.md plus scoped docs, extensions, plugin SDK, plugins, outbound, agents, and scripts guides; these make public SDK/config/plugin/security/channel-routing changes compatibility-sensitive. (AGENTS.md:13, 0503853c294b)
• Access-group webhook admission bug: The PR head treats any allowFrom accessGroup entry as sufficient authorization before checking whether the sender belongs to that group. (extensions/channel-broker/src/http-routes.ts:73, e17119999aa4)
• Existing access-group contract requires membership resolution: Current main exposes resolveAccessGroupAllowFromState, which resolves referenced group names and only records matches after sender membership checks. (src/plugin-sdk/access-groups.ts:50, 0503853c294b)
• Standard ingress path resolves access groups later: The normal ingress resolver gathers referenced access groups and resolves runtime membership before projecting sender access, so the new HTTP pre-gate should not wildcard group references. (src/channels/message-access/runtime.ts:628, 0503853c294b)
• Current main does not already implement the broker: A current-main source search found no channel-broker implementation, so the PR is not obsolete or implemented on main. (0503853c294b)
• Proof is stale to the live head: The PR body still names head 7614f3b, while the live PR API reports head e171199. (e17119999aa4)

Likely related people:

• Peter Steinberger: Current-main blame on the channel target-prefix helper and channel ingress access-group resolver points to the current checked-out main commit for adjacent routing/access behavior. (role: recent adjacent area contributor; confidence: medium; commits: 6b391efa4e69; files: src/infra/outbound/channel-target-prefix.ts, src/channels/message-access/runtime.ts)
• vincentkoc: Live PR history shows vincentkoc authored the latest Channel Broker target-preservation repairs, including the current Slack broker route-target commit. (role: recent PR repair contributor; confidence: medium; commits: e17119999aa4, 8854f360df95, f3f922ba437f; files: extensions/channel-broker/src/target.ts, extensions/channel-broker/src/channel.test.ts)

What the crustacean ranks mean

• 🦀 challenger crab: rare, exceptional readiness with strong proof, clean implementation, and convincing validation.
• 🦞 diamond lobster: very strong readiness with only minor maintainer review expected.
• 🐚 platinum hermit: good normal PR, likely mergeable with ordinary maintainer review.
• 🦐 gold shrimp: useful signal, but proof or patch confidence is still limited.
• 🦪 silver shellfish: thin signal; proof, validation, or implementation needs work.
• 🧂 unranked krab: not merge-ready because proof is missing/unusable or there are serious correctness or safety concerns.
• 🌊 off-meta tidepool: rating does not apply to this item.

Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics.

How this review workflow works

• ClawSweeper keeps one durable marker-backed review comment per issue or PR.
• Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
• A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
• PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
• Maintainers can also comment @clawsweeper review to request a fresh review only.
• Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
• Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
• Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.

[clawsweeper]

ClawSweeper PR egg

🎁 Pass real behavior proof to wake the egg and unlock a hatchable treat.

Where did the egg go?

• The egg game starts only after the PR passes the real-behavior proof check.
• Before that, no creature or rarity is rolled. The treat waits for real proof.
• This is still just collectible flavor: proof affects review readiness, not creature quality.

[socket-security]

No dependency changes detected. Learn more about Socket for GitHub.

👍 No dependency changes detected in pull request

[github-actions]

Dependency Changes Detected

This PR changes dependency-related files. Maintainers should confirm these changes are intentional.

Changed files:

• extensions/channel-broker/package.json
• package.json
• pnpm-lock.yaml

Maintainer follow-up:

• Review whether the dependency changes are intentional.
• Inspect resolved package deltas when lockfile, shrinkwrap, or workspace dependency policy changes are present.
• Treat package-lock.json and npm-shrinkwrap.json diffs as security-review surfaces.
• Run pnpm deps:changes:report -- --base-ref origin/main --markdown /tmp/dependency-changes.md --json /tmp/dependency-changes.json locally for detailed release-style evidence.

[vincentkoc]

Hi Eva,

Thank you for putting this together and for the amount of work that clearly went into the Channel Broker stack. I'm sorry to close it after that investment, but we are not going to accept this PR stack.

The changes reach too deeply across OpenClaw's channel, plugin SDK, runtime, config, and security boundaries to land without prior maintainer consultation and an agreed design plan. This needs to start as a smaller design discussion with maintainer-approved boundaries before code of this scope can be considered.

I'm closing this PR and the linked phase stack for the same reason. Thank you again for the contribution.