feat(slack): add relay mode for incoming messages#94707
Conversation
|
Codex review: needs maintainer review before merge. Reviewed June 21, 2026, 9:46 AM ET / 13:46 UTC. Summary PR surface: Source +778, Tests +375, Docs +48, Config +1, Generated 0, Other +3. Total +1205 across 34 files. Reproducibility: not applicable. this is a feature PR, not a current-main bug report; the supplied proof demonstrates after-fix relay behavior rather than a failing reproduction path. Review metrics: 2 noteworthy metrics.
Stored data model Merge readiness Overall follows the weaker of proof and patch quality, so missing proof can cap an otherwise strong patch. Rank-up moves:
Mantis proof suggestion Risk before merge
Maintainer options:
Next step before merge
Security Review detailsBest possible solution: Have maintainers/security explicitly sponsor the relay trust boundary and dependency graph change, then either land this Slack-plugin implementation with green current-head checks or consolidate it with the trusted-upstream direction if one trusted Slack ingress primitive is preferred. Do we have a high-confidence way to reproduce the issue? Not applicable: this is a feature PR, not a current-main bug report; the supplied proof demonstrates after-fix relay behavior rather than a failing reproduction path. Is this the best way to solve the issue? Unclear until maintainer/security decision: the Slack plugin boundary is plausible and the current head addresses ACK and identity handling, but maintainers must decide whether relay should ship separately or be consolidated with trusted-upstream work. AGENTS.md: found and applied where relevant. Codex review notes: model internal, reasoning high; reviewed against 11a2e03bd4de. Label changesLabel changes:
Label justifications:
Evidence reviewedPR surface: Source +778, Tests +375, Docs +48, Config +1, Generated 0, Other +3. Total +1205 across 34 files. View PR surface stats
Security concerns:
What I checked:
Likely related people:
What the crustacean ranks mean
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
|
Dependency GuardThis PR changes dependency-related files. Maintainers should confirm these changes are intentional. Changed files:
Maintainer follow-up:
|
Dependency graph changes are blockedOpenClaw does not accept dependency graph changes through PRs unless a repository admin or security explicitly authorizes the current head SHA. Dependency updates are generated internally by maintainers so external PRs cannot change the resolved graph. Detected dependency graph changes:
Auto-scrub was not attempted because this PR changes package manifest dependency graph fields:
Dependency graph changes must be reviewed by security or handled by maintainers internally. Please remove lockfile changes manually if they are not needed. To remove lockfile changes, restore them from the target branch: git fetch origin
git checkout 'origin/main' -- 'extensions/slack/npm-shrinkwrap.json' 'pnpm-lock.yaml'
git commit -m 'chore: remove dependency lockfile change'
git pushIf this PR intentionally needs a dependency graph change, ask a repository admin or member of The action will approve the current head SHA ( |
78b1994 to
b480796
Compare
b480796 to
cd3a3e2
Compare
|
Pilot end-to-end evidence from the repaired relay head:
Observed Slack round trips through the central router and the two relay-connected gateways:
Both permanent gateway smoke turns also completed through the bundled Codex provider ( Two pilot-level environment issues remain outside this relay implementation: Slack reports |
|
Final pilot evidence from the repaired relay head
The outbound identity fix deliberately bypasses Slack's native streaming API whenever a routed custom identity is present, because Slack's streaming methods do not expose One operational issue remains outside this PR: Socket Mode reports another consumer for the same app token, so that external consumer can intermittently receive a human event before this router does. The gateway pods do not hold the app token or run direct Socket Mode. Removing the unknown consumer or rotating the app token is still required for deterministic single-consumer routing. The remaining expected merge blocker is the dependency guard approval for the Slack plugin-local |
|
You are seeing this message because GitHub Code Scanning has recently been set up for this repository, or this pull request contains the workflow file for the Code Scanning tool. What Enabling Code Scanning Means:
For more information about GitHub Code Scanning, check out the documentation. |
What Problem This Solves
OpenClaw gateways currently need to own Slack Socket Mode connections directly. That makes it difficult for an external
openclaw-slack-routerto maintain the Slack connection and route user-group mentions to the appropriate gateway.This change adds a Slack
relayconnection mode so a gateway can receive routed Slack events over a websocket while continuing to use Slack’s Web API for outbound messages.Why This Change Was Made
Relay mode authenticates with a bearer token and
gatewayId, reconnects using the existing Slack backoff policy, serializes inbound frame handling, reports connection health, and dispatches events through the normal Slack message handler. Relay events are treated as authorized mentions because the router has already selected the target gateway, and OpenClaw acknowledges each valid routed Slack message delivery after message handling completes.The router can provide
username,icon_url, oricon_emojiin its websockethelloframe. OpenClaw stores that identity per Slack account and uses it for outboundchat.postMessagecalls unless the caller supplies an explicit identity. The stored identity is cleared when the relay disconnects or the provider stops.Relay mode adds these settings at the top level or per account:
mode: "relay"relay.urlrelay.authToken(including SecretInput resolution and secret-audit support)relay.gatewayIdRelay accounts still require a bot token for outbound Slack API calls, but do not require a Slack app token or HTTP signing secret. Existing Socket Mode and HTTP behavior remains unchanged.
User Impact
Operators can run Slack connectivity through a central router and route user-group mentions to the correct OpenClaw gateway without changing the existing Slack processing, persona, or outbound delivery path.
The change also exposes the new mode through Slack account inspection, setup metadata, configuration schemas, UI hints, and generated channel metadata.
Evidence
oxfmt.oxlint.git diff --checkon the identity changes.tsc -p extensions/slack/tsconfig.json --noEmitattempt was blocked by the existing unrelated missing-module error inextensions/slack/src/outbound-payload.test-harness.ts.