Beeper displays conversations from supported external messaging accounts inside one client. It does not replace the account held by WhatsApp, Signal, Telegram or another connected service. A separate bridge links each chat-network account to Beeper and Matrix, while the original network still controls its own account and message capabilities.
Support differs by network. One bridge may import earlier direct messages, while another brings only recent material or no earlier history. The connection therefore cannot promise a complete copy of the archive visible in the native client.
On-device and cloud connections keep different state
An on-device connection runs only on the Beeper device where the user configured it. Its documentation says that those messages do not leave that device for Beeper storage, although the original chat service still handles them. The same connection does not appear automatically on the user’s other signed-in devices.
A cloud connection stays attached to the account and appears across signed-in devices. Its encrypted data passes through its servers. Logging out deletes on-device connections, while cloud connections remain attached to the account.
There is no instant mode switch. Moving a network between on-device and cloud requires removing its connection and configuring it again. On-device bridging also needs unrestricted battery and data access, and some networks only expose the cloud route.
History import follows the connected network
History import may deliver a complete set or only recent material. Some networks queue older batches, while another network may provide no earlier history. Some end-to-end encrypted conversations stay absent even when ordinary conversations from the same service appear. Direct-message history and channel history can also follow different import rules.
This uneven backfill matters after reconnection. The bridge can work for new messages while an older conversation remains missing. Waiting for a queued import and assuming that an unsupported archive will appear are different actions.
The Recovery Code protects Beeper history
The Recovery Code unlocks encrypted Beeper history and verifies Beeper sessions. The Recovery Code is case-sensitive. Beeper keeps no recoverable copy. The code belongs to the account rather than one phone or computer.
Resetting a lost code creates a new encryption key. The reset disconnects every chat network. The user must connect each network again afterward. History encrypted under the former code remains inaccessible unless the upstream network can backfill a copy after reconnection.
Another signed-in device that still uses the old key can show encrypted-message placeholders. It must sign out and then sign in again. The replacement code verifies that session.
The browser extension hands off an existing login
The browser extension can pass an existing supported web login to the desktop client with the user’s permission. Completing that handoff logs the same service out of the browser. The extension then opens the desktop client to finish adding the account; the extension is not a separate message client.
Account limits or an existing cloud connection can hide one of the connection choices. A missing choice does not necessarily mean that the browser handoff failed.
Some native apps still need to remain
Several chat networks require their official app to stay installed on an active phone for the Beeper connection to work. Some actions also remain unavailable in Beeper even when message access works, which is why the official guidance recommends keeping the native apps.
Removing a chat network erases its Beeper-side rooms and stored message material. The removal leaves upstream conversations on the original service. Reconnecting can restore only the history that the network’s current backfill path supports, so removal is not a neutral first troubleshooting step.
