docs: Telegram/Discord channel integration research

[aterrylu]

Summary

Research doc evaluating how to integrate Telegram and Discord as messaging channels for autonomOS-spawned sessions. Investigates three options (Terry's A/B + hybrid C), verifies the premise from primary sources, and recommends a path.

TL;DR

Recommendation: Option B (lean on CC native channels) for MVP, Option C (hybrid + gateway adapters) for proactive outbound in Phase 2.

Why: autonomOS already uses Claude Code's channel protocol. Our server:autonomos is a claude/channel capability MCP server, and packages/server/src/providers/claude-code.ts:136-146 already wires both --channels and --dangerously-load-development-channels. Extending to Telegram/Discord is just adding plugin URIs to settings.channels — no code change needed for inbound. MVP effort: ~1 day of dashboard UI + docs.

The only real gap Option B doesn't cover is proactive outbound (agent sends to a Telegram chat it hasn't received a message from). That becomes Phase 2 by completing the existing gateway adapter stubs.

Key findings

• Premise verified: code.claude.com/docs/en/channels is real, shipped in v2.1.80+, includes Telegram/Discord/iMessage/fakechat plugins
• Resume continuity: free — channels live in global settings, buildArgs re-reads them on every spawn including resume
• Permission relay: CC channels support claude/channel/permission (approve tool use from phone) — significant UX we'd lose if we went DIY
• OpenClaw correction: OpenClaw (Peter Steinberger's framework) is NOT Claude Code. Terry's "super smooth UX" memory is from OpenClaw's gateway system. Transferable UX lessons only
• Enterprise gate: channelsEnabled managed setting can block channels on Team/Enterprise plans (Pro/Max skip this)

What's in the doc

docs/research/channel-integration.md contains the seven required sections:

1. Premise verification (with primary sources)
2. Architecture comparison A/B/C/D with tradeoff matrix
3. OpenClaw UX teardown — what to copy, what to improve
4. Resume continuity — mechanical proof both options are safe
5. Spawning new channels (bonus) — 4-level UX progression proposal
6. Recommendation with phased implementation plan
7. Implementation handoff for Phase 1 (files to touch / not touch, success criteria, edge cases)

Test plan

• Doc renders on GitHub (markdown)
• All file-path links resolve (relative to repo root)
• Primary sources linked
• Terry reviews TL;DR + recommendation — redirect if Option A/C is preferred

🤖 Generated with Claude Code

[nox-0x]

Solid research doc. Options A/B/C/D tradeoff matrix is clear, the CC channels flag wiring at claude-code.ts:136-146 checks out against the actual code, and the phased implementation plan is actionable. The one thing worth keeping in mind as you move to Phase 1: the docs/setup/channels.md preflight checklist should explicitly test that the autonomOS server process has network access to Telegram's API — if it's running in a restricted network namespace, the plugin pairing flow will fail silently and it's not obvious why. LGTM ✅