Cloud messaging: send and receive afx-style messages via Codev Cloud

[waleedkadous]

Summary

Add the ability to send and receive afx send-style messages to/from running builder and architect sessions through Codev Cloud, authenticated via API key.

Motivation

Currently afx send only works locally — you must be on the same machine as Tower. For distributed teams or remote monitoring, there's no way to message a builder or receive notifications about gate approvals, PR readiness, etc. without being at the terminal.

Key Context

Existing Infrastructure

• Codev Cloud tunnel: Tower already maintains an HTTP/2-over-WebSocket tunnel to cloud.codevos.ai. All Tower API routes (including POST /api/send) are already proxied through the tunnel.
• afx send local flow: CLI → POST /api/send → Tower resolves target terminal → writes to PTY + broadcasts via WebSocket message bus.
• Cloud auth: Towers authenticate with ctk_ API keys via WebSocket auth message. Browser access uses the tunnel proxy at /t/{towerId}/....

Claude Channels (new Claude Code feature)

• MCP servers that push events into running Claude Code sessions
• Two-way channels can both receive events AND reply back
• Uses notifications/claude/channel for inbound messages
• Exposes MCP tools (e.g., reply) for outbound messages
• Permission relay capability for remote tool approval
• Could be used as the "receive side" — a Codev Cloud channel MCP server that connects to the cloud and forwards messages into the local session

Possible Approach

1. Send (remote → Tower): Cloud API endpoint that accepts authenticated messages and proxies them through the tunnel to Tower's /api/send endpoint. Essentially a cloud-hosted afx send.

2. Receive (Tower → remote): A Claude Channel (MCP server) that subscribes to Tower's WebSocket message bus and forwards messages to the Claude Code session. Could also push to the cloud for web/mobile consumption.

3. Authentication: API key-based. Could reuse the existing ctk_ tower keys, or introduce separate messaging keys with scoped permissions.

Open Questions

• Should this use Claude Channels as the receive mechanism, or build a separate notification system?
• What authentication model for message senders? Same tower key, separate keys, or invite-based?
• Should there be a web UI on codevos.ai for sending/reading messages?
• Rate limiting and abuse prevention for cloud-routed messages?

Scope

This is an investigation/spec — the builder should explore the architecture and propose a concrete design.