#16954: feat(rocketchat): add Rocket.Chat channel plugin

## Summary - **Problem:** No Rocket.Chat integration exists, leaving self-hosted Rocket.Chat users unable to connect Clawdbot to their instances - **Why it matters:** Rocket.Chat is widely used in self-hosted environments; this fills a gap in the channel ecosystem - **What changed:** Added a new `extensions/rocketchat/` plugin mirroring the Mattermost architecture, adapted for Rocket.Chat APIs - **What did NOT change (scope boundary):** No existing code modified; purely additive extension ## Change Type (select all) - [ ] Bug fix - [x] Feature - [ ] Refactor - [ ] Docs - [ ] Security hardening - [ ] Chore/infra ## Scope (select all touched areas) - [ ] Gateway / orchestration - [ ] Skills / tool execution - [ ] Auth / tokens - [ ] Memory / storage - [x] Integrations - [ ] API / contracts - [ ] UI / DX - [ ] CI/CD / infra ## Linked Issue/PR - Closes #16926 ## User-visible / Behavior Changes - New `rocketchat` channel available as a plugin - Users can configure via `channels.rocketchat` config section or env vars (`ROCKETCHAT_AUTH_TOKEN`, `ROCKETCHAT_USER_ID`, `ROCKETCHAT_URL`) - CLI onboarding wizard guides Personal Access Token setup - Supports DMs, channels, groups, threads, file attachments, mention-gating, pairing, and multi-account ## Security Impact (required) - New permissions/capabilities? (`Yes` — new channel integration) - Secrets/tokens handling changed? (`Yes` — Rocket.Chat auth tokens stored in config/env) - New/changed network calls? (`Yes` — REST API v1 + WebSocket to user's Rocket.Chat server) - Command/tool execution surface changed? (`No`) - Data access scope changed? (`No`) - Risk + mitigation: Auth tokens follow the same config/env pattern as existing channels (Mattermost, Slack, etc.). No new credential storage mechanisms introduced. ## Repro + Verification ### Environment - OS: Any - Runtime: Node.js - Integration/channel: Rocket.Chat (self-hosted) ### Steps 1. Install the rocketchat plugin 2. Configure with `ROCKETCHAT_AUTH_TOKEN`, `ROCKETCHAT_USER_ID`, `ROCKETCHAT_URL` 3. Start the gateway 4. Send a DM to the bot user on Rocket.Chat ### Expected - Bot connects via WebSocket and responds to messages ### Actual - (New feature — expected behavior described above) ## Evidence - [x] 13 unit tests passing (`extensions/rocketchat/src/channel.test.ts`) - [x] Lint: 0 warnings, 0 errors - [x] Format: all files correctly formatted ## Human Verification (required) - Verified scenarios: Unit tests cover messaging normalization, target resolution, pairing entry normalization, allowFrom formatting, config detection, and responsePrefix overrides - Edge cases checked: Empty strings, prefixed targets (`@user`, `#channel`, `user:`, `channel:`, `rocketchat:`), and missing credentials - What was not verified: Live Rocket.Chat server integration (requires running instance) ## Compatibility / Migration - Backward compatible? (`Yes`) - Config/env changes? (`Yes` — new optional env vars) - Migration needed? (`No`) ## Failure Recovery (if this breaks) - How to disable/revert: Remove/uninstall the rocketchat plugin - Files/config to restore: None (purely additive) - Known bad symptoms: If Rocket.Chat server is unreachable, the plugin reconnects with exponential backoff ## Risks and Mitigations - Risk: Rocket.Chat API differences across versions may cause issues - Mitigation: Uses stable REST v1 API endpoints; WebSocket uses standard DDP protocol --- 🤖 Generated with Claude Code (issue-hunter-pro) <!-- greptile_comment --> <h3>Greptile Summary</h3> Adds a new `extensions/rocketchat/` plugin providing Rocket.Chat channel integration, mirroring the existing Mattermost plugin architecture. The plugin supports DMs, channels, groups, threads, file attachments, mention-gating, pairing, and multi-account configuration via Personal Access Tokens. The implementation is well-structured and follows established patterns from other channel plugins (config schema, account resolution, onboarding wizard, reconnection with backoff). Key concerns: - **WebSocket login race condition**: Room subscriptions are sent immediately after the DDP `login` call without waiting for the server's `result` response. If the auth token is invalid/expired, login failure goes completely undetected — the bot appears connected but silently receives no messages, with no error surfaced. This will make credential issues very difficult to diagnose in production. - **Dead placeholder code**: `monitor.ts` contains a `fileUrl` variable assigned to an unrelated endpoint (`/e2e.fetchMyKeys`) that is immediately voided — leftover development scaffolding. - **Missing `.github/labeler.yml` update**: Per `AGENTS.md`, new extensions should add a matching label entry. <h3>Confidence Score: 3/5</h3> - Purely additive plugin with no changes to existing code, but the WebSocket authentication flow has a silent-failure risk that could make debugging difficult in production. - Score of 3 reflects that the plugin is purely additive (no risk to existing functionality), follows established patterns well, and has good test coverage for config/normalization. However, the DDP login race condition means the bot could silently fail to receive messages without any error surfaced, which is a meaningful operational concern for production deployments. - Pay close attention to `extensions/rocketchat/src/rocketchat/monitor-websocket.ts` (login/subscription race condition) and `extensions/rocketchat/src/rocketchat/send.ts` (previously flagged user:ID target issue). _{Last reviewed commit: 0ba1d3c} <!-- greptile_other_comments_section --> **Context used:** - Context from `dashboard` - CLAUDE.md ([source](https://app.greptile.com/review/custom-context?memory=fd949e91-5c3a-4ab5-90a1-cbe184fd6ce8)) <!-- /greptile_comment -->