Feature request: Local-only mode without cloud relay + RCS support for AI agent integration

[GURSEWAKSINGHSANDHU]

Context

I've been building an AI-powered SMS automation system using TextBee as the SMS gateway on a Samsung Galaxy S24+ connected to a Dell server via Tailscale. The setup:

Incoming SMS → TextBee App → TextBee Cloud → Webhook → Express.js → Claude AI → TextBee API → Outgoing SMS

TextBee works for basic SMS sending/receiving, but there are some limitations that made me explore alternatives for AI agent integration.

Limitations Encountered

1. Cloud Relay for Private Messages

All messages route through TextBee's cloud servers before reaching my local webhook. For an AI agent handling insurance quotes and customer conversations, having private SMS content pass through a third-party server is a concern.

Request: A local-only / self-hosted mode where the Android app connects directly to a local server (via LAN IP or Tailscale) without the cloud relay. The phone and server are on the same Tailscale network — there's no need for cloud routing.

2. SMS Only — No RCS Support

In 2025+, most Android-to-Android conversations default to RCS with end-to-end encryption. TextBee can only access plain SMS messages. This means:

• AI agent can't read or respond to RCS conversations
• Customers who have RCS enabled (most modern Android phones) need to have it disabled or the messages fall back to SMS
• No support for read receipts, typing indicators, or high-res media that RCS provides

Request: RCS message access via Android's messaging APIs, or at minimum, documentation on whether RCS support is technically feasible given Android's API restrictions.

3. No Conversation Threading

The REST API returns individual messages without conversation context. For an AI agent that needs to understand conversation history (e.g., "the customer asked about insurance pricing 3 messages ago"), you need to build your own conversation threading on top of the raw message feed.

Request: A /conversations endpoint that groups messages by contact/thread, similar to how messaging apps display them.

4. Complex Webhook Pipeline

To receive incoming messages, you need:

1. TextBee app running on the phone
2. TextBee cloud relay
3. A publicly accessible webhook URL (requires ngrok/Tailscale Funnel/etc.)
4. A webhook server (Express.js, etc.)
5. API client for sending replies

That's 5 components for basic bidirectional SMS. A local WebSocket connection between the phone app and server would reduce this to 2 components.

5. Battery and Resource Usage

The TextBee app needs to run continuously on the phone to maintain the gateway. On a daily-driver phone (not a dedicated device), this adds to battery drain and mobile data usage.

What I Ended Up Building

Due to these limitations, I built a Chrome extension that bridges to Google Messages Web directly:

• No cloud relay — everything stays local
• RCS support — reads and writes RCS conversations natively
• Conversation threading — built into Google Messages
• No phone app — uses the already-paired browser session

Repo: https://github.com/GURSEWAKSINGHSANDHU/google-messages-mcp

TextBee is still great for dedicated SMS gateway use cases. These suggestions are aimed at making it more suitable for AI agent / MCP integration where privacy, RCS, and conversation context matter.

Suggestions Summary

1. Local-only mode — Direct connection between phone app and local server without cloud relay
2. RCS support — Access to RCS messages via Android APIs
3. Conversation endpoint — /conversations API grouping messages by thread
4. WebSocket push — Real-time message delivery via WebSocket instead of webhook polling
5. MCP server built-in — A built-in MCP server (stdio) would make TextBee immediately usable with Claude Code, Cursor, and other AI tools without custom middleware