← Back to PRs

#20348: Add support for Keybase as a channel

by xgess open 2026-02-18 20:27 View on GitHub →
docs channel: bluebubbles size: XL
Summary - Problem: OpenClaw has no support for Keybase messaging — users who rely on Keybase for end-to-end encrypted communication can't use it as a channel. - Why it matters: Keybase offers E2E encrypted messaging with a simple CLI API, making it a good fit for privacy-conscious users and teams already in the Keybase ecosystem. It's also very easy to create new keybase bot identities without needing a real, verifiable phone number. This makes it fast and easy to spin up new agents. - What changed: Added a full Keybase channel plugin following the existing channel plugin architecture. Inbound via keybase chat api-listen, outbound via keybase chat api. Supports DMs and team channels with allowlist, pairing, and open access policies. - What did NOT change: No changes to the core gateway, agent pipeline, or other channel plugins beyond the minimal wiring required (registry, dock, plugin runtime types). The bluebubbles test mock was updated to include the new keybase runtime entry. Change Type (select all) - Bug fix - Feature - Refactor - Docs - Security hardening - Chore/infra Scope (select all touched areas) - Gateway / orchestration - Skills / tool execution - Auth / tokens - Memory / storage - Integrations - API / contracts - UI / DX - CI/CD / infra Linked Issue/PR - Related # (none — new feature) User-visible / Behavior Changes - New channels.keybase config section with enabled, dmPolicy, allowFrom, groupPolicy, groupAllowFrom fields. - New keybase entry in channel registry (appears in channel selection, status, and doctor). - New extension plugin @openclaw/keybase auto-enabled when keybase config is present. - Keybase channel appears in onboarding wizard. Security Impact (required) - New permissions/capabilities? Yes — spawns keybase chat api-listen and keybase chat api as child processes. - Secrets/tokens handling changed? No — uses the host's logged-in Keybase session, no tokens stored by OpenClaw. - New/changed network calls? Yes — Keybase CLI makes network calls to Keybase servers (not OpenClaw directly). - Command/tool execution surface changed? Yes — two new child process spawn points (execFile("keybase", ...) for send/probe, spawn("keybase", ["chat", "api-listen"]) for monitoring). - Data access scope changed? No - Risk + mitigation: Child process spawns use execFile (not exec), avoiding shell injection. Arguments are passed as arrays, not interpolated strings. The Keybase CLI path is not user-configurable — it uses the system keybase binary. Repro + Verification Environment - OS: macOS (Darwin 24.6.0) - Runtime/container: Node 22, pnpm via corepack - Model/provider: Anthropic Claude (via setup-token) - Integration/channel: Keybase CLI v6.5.1 - Relevant config: { channels: { keybase: { enabled: true, dmPolicy: "allowlist", allowFrom: ["<username>"] } } } Steps 1. Install Keybase CLI, log in (keybase login), verify (keybase whoami). 2. Add keybase channel config to openclaw.json with an allowlisted username. 3. Start the gateway (openclaw gateway). 4. Send a DM from the allowlisted Keybase user to the bot's Keybase username. Expected - Gateway logs show [keybase] logged in as <bot> and listening for messages via api-listen. - Inbound message is received, processed by the agent, and a reply is delivered back to the Keybase conversation. Actual - Works as expected. Full round-trip verified: message received, agent replied, reply delivered. Evidence - Failing test/log before + passing after - Trace/log snippets 26/26 unit tests pass (identity + normalize): ✓ src/keybase/identity.test.ts (18 tests) ✓ src/keybase/normalize.test.ts (8 tests) Gateway log showing successful round-trip: [keybase] [default] starting keybase provider [keybase] logged in as excel_song_swap [keybase] listening for messages via api-listen [keybase] delivered reply to xgess TypeScript: zero errors (tsc --noEmit). Human Verification (required) - Verified scenarios: End-to-end DM round-trip (send message from allowlisted user → agent processes → reply delivered via Keybase). Verified keybase whoami detection, api-listen lifecycle, outbound chat api send. - Edge cases checked: Allowlist enforcement (only allowlisted users accepted), self-message filtering (bot doesn't echo its own replies), config auto-detection by doctor. - What I did not verify: Team channel messages, pairing flow, multi-account config, process crash recovery/restart, group mention gating. Compatibility / Migration - Backward compatible? Yes — purely additive, no existing behavior changes. - Config/env changes? Yes — new optional channels.keybase config section. - Migration needed? No - Existing users without keybase config are completely unaffected. Failure Recovery (if this breaks) - How to disable/revert: Set channels.keybase.enabled: false in config, or remove the channels.keybase section entirely. - Files/config to restore: No migration to undo — just remove config. - Known bad symptoms: If keybase CLI is not installed or not logged in, the monitor will fail at startup with keybase: failed to detect username. This only affects the keybase channel; other channels are unaffected. Risks and Mitigations - Risk: keybase chat api-listen process could exit unexpectedly (Keybase service crash, logout). - Mitigation: Monitor logs the exit and the gateway's health monitor will report the channel as down. Restart the gateway to recover. - Risk: Keybase CLI not present on host — gateway startup logs an error for the keybase channel. - Mitigation: Only affects keybase; other channels start normally. Error message is clear about the cause. <!-- greptile_comment --> <h3>Greptile Summary</h3> This PR adds a full Keybase channel plugin following the existing channel plugin architecture. It introduces inbound messaging via `keybase chat api-listen` and outbound via `keybase chat api`, with support for DMs and team channels using the standard allowlist, pairing, and open access policies. - **28 new/modified files** across core (`src/keybase/`, `src/channels/`, `src/config/`, `src/plugins/`) and extension (`extensions/keybase/`) directories, adding ~1,920 lines - Follows existing channel patterns (Signal, Telegram, etc.) closely: monitor, event handler, identity, send, probe, normalize, onboarding, dock, and registry entries all mirror established conventions - Security: uses `execFile` (not `exec`) with array arguments for child process spawns, avoiding shell injection. Uses host Keybase session — no tokens stored by OpenClaw - Zod config schema includes proper `requireOpenAllowFrom` validation, matching other channels - Unit tests cover identity (18 tests) and normalize (8 tests) functions - Missing `.github/labeler.yml` entry for the `channel: keybase` label (required per AGENTS.md when adding new channels) - Missing `docs/docs.json` navigation entry — the `docs/channels/keybase.md` page exists but won't appear in the Mintlify docs sidebar under "Messaging platforms" <h3>Confidence Score: 4/5</h3> - This PR is safe to merge — purely additive with no changes to existing behavior, though two config/docs entries are missing. - Score of 4 reflects a well-structured, additive feature that follows existing channel patterns closely. The implementation is clean with proper security practices (execFile, no shell injection). Deducted one point because the `.github/labeler.yml` and `docs/docs.json` navigation entries are missing per repo guidelines (AGENTS.md). The code itself has no logical issues — it's a mechanical extension of well-established patterns. Unit tests cover the core identity and normalize functions adequately. - `.github/labeler.yml` needs a `channel: keybase` entry. `docs/docs.json` needs `channels/keybase` added to the "Messaging platforms" navigation group. <sub>Last reviewed commit: 0fe92c1</sub> <!-- greptile_other_comments_section --> <sub>(2/5) Greptile learns from your feedback when you react with thumbs up/down!</sub> **Context used:** - Context from `dashboard` - CLAUDE.md ([source](https://app.greptile.com/review/custom-context?memory=fd949e91-5c3a-4ab5-90a1-cbe184fd6ce8)) - Context from `dashboard` - AGENTS.md ([source](https://app.greptile.com/review/custom-context?memory=0d0c8278-ef8e-4d6c-ab21-f5527e322f13)) <!-- /greptile_comment -->

Most Similar PRs