OpenClaw iOS app: offline chat, queued sends, and safer reconnects
The OpenClaw iOS app is useful when it preserves the thread you were already working in, rather than pretending a phone has become a second agent host. After pairing, the app keeps a small read-only cache of recent chats for each Gateway and can put text messages into a durable, per-Gateway outbox while the phone is offline. On reconnect, those messages flush in order with idempotent retries. That is the difference between a mobile companion and a chat app that merely looks connected until it is not.
This guide covers the post-pairing behavior. If you still need to connect a phone, start with the OpenClaw mobile app pairing guide. For the larger architecture, read what OpenClaw is and how OpenClaw works.
Table of contents
- What offline chat means in the OpenClaw iOS app
- How queued sends avoid a duplicate-message problem
- Use reconnects as a state check, not a blind retry
- A practical mobile workflow
- FAQ
What offline chat means in the OpenClaw iOS app
The OpenClaw iOS app connects to a Gateway running elsewhere. The Gateway remains the authority for agent sessions, routing, tools, and the record of a completed turn. The phone gives an operator a focused surface for chat, voice, approvals, sharing, and permitted device capabilities.
That distinction matters when the network disappears. According to the iOS documentation, the app stores a small read-only cache of recent sessions and transcripts for each paired Gateway. A cold open can show the last known transcript immediately, recent chats remain browseable while disconnected, and the app refreshes the view after the Gateway responds again.
The cache is deliberately local and limited. It helps you answer questions such as “which session was this?” or “what did the agent last say?” It does not turn an old screen into a live record. A tool call might have finished elsewhere, another operator might have replied, or the Gateway might have restarted while the phone slept.
| Situation | What the iOS app can preserve | What still belongs to the Gateway |
|---|---|---|
| Phone briefly loses service | Recent cached sessions and transcripts | Current agent and tool state |
| You write a text reply offline | A durable queued message for the selected Gateway | Whether the reply becomes part of canonical history |
| Another surface resolves an approval | The app can read back the terminal result | The decision itself and its audit record |
| You switch between Gateways | Per-Gateway credentials, preferences, and cached history | Which Gateway owns the active iPhone node session |
OpenClaw v2026.7.1 expanded the official iOS, Android, and macOS apps across setup, navigation, chat, voice, permissions, files, scheduled work, native session controls, and Gateway recovery. The release notes also describe the shared goal plainly: recent conversations should remain useful during temporary disconnects, with cached sessions available to read and supported text sends able to wait for reconnection in the correct chat.
How queued sends avoid a duplicate-message problem
A useful offline outbox needs more than a spinner and a retry button. The iOS documentation says disconnected text messages are written to a durable outbox per paired Gateway, up to 50 queued messages. The app shows the queued bubble in the transcript, flushes it in order after reconnecting, retries with an idempotency key, and keeps it until canonical history confirms the send.
That last condition is the important one. A network acknowledgement can be lost after the Gateway accepted a message. If the app simply retries, it may create two identical instructions. If it marks the send complete too early, it may tell you the message arrived when it did not. OpenClaw keeps the queued item until the Gateway’s canonical history provides the stronger proof.
Use the visible state as your guide:
- If a text bubble says it is queued, leave it alone while the app reconnects.
- If the app surfaces a retry or delete choice after backoff, decide whether the message still makes sense in the current session.
- Do not copy and paste the same instruction into another channel “just in case.” That defeats the outbox’s duplicate protection and can give an agent conflicting work.
- If the message was time-sensitive, rewrite it after you can see the fresh session state. The iOS outbox expires a queued message after 48 hours instead of delivering a stale command later.
The scope is intentionally narrow. The iOS app queues text; it does not promise that every interaction can happen in the background. Camera, screen, canvas, and Talk actions have iOS foreground requirements. Treat the phone as a way to preserve continuity around an agent run, not as a guarantee that every node capability is always awake.
Use reconnects as a state check, not a blind retry
The safest reconnect behavior is read-before-write. When an approval or question may have been handled on the Control UI, another phone, or a chat channel, the iOS app checks the Gateway’s canonical terminal record. Actions remain unavailable until that readback confirms whether the request is still pending.
That behavior is easy to underestimate. A late “approve” tap should not override an outcome that was already decided elsewhere. It also keeps an approval tied to the selected Gateway: switching Gateways cannot apply an old prompt to the new connection.
Use the same discipline for chat:
- Reopen the session after the connection returns and read the newest Gateway-backed messages.
- Check whether an agent requested clarification, completed the task, or moved to a different state before sending a follow-up.
- Use a fresh message when the context changed; do not rely on an old offline draft to express a decision made hours ago.
- Keep configuration changes on a larger control surface where the full scope is visible. The Control UI workspace guide is a better place to inspect parallel work and broad administrative changes.
This is especially useful for long-running work. The mobile AI agent sessions guide explains how push and realtime sessions help operators return to the right run. The iOS app adds a local continuity layer, but the Gateway still decides what actually happened.
A practical mobile workflow
After you have paired the app over a protected route, use this small operating routine:
- Choose the right Gateway before acting. The app keeps credentials, TLS decisions, preferences, and cached chats separately for each paired Gateway. The focused Gateway owns the capability-bearing iPhone node session.
- Read before you send. Cached history is helpful for orientation. Once connected, wait for the Gateway refresh before making a decision based on the latest agent state.
- Queue one clear text instruction. If the phone is offline, let the outbox own delivery. Do not send the same instruction through a second surface unless you intentionally want two requests.
- Review stale queued messages. An instruction that was safe during a commute may be wrong after a task has finished. Delete it or rewrite it when the session returns.
- Expect foreground limits. Use chat and operator controls for continuity. Bring the app to the foreground for device actions that iOS cannot safely service in the background.
For a device that is lost, replaced, or no longer trusted, forget or revoke the pairing rather than assuming an old mobile cache has expired. The iOS documentation states that forgetting a Gateway removes its credentials, device tokens, TLS pin, and cached chats from the phone.
FAQ
Can the OpenClaw iOS app send a message while offline?
Yes, for supported text messages. The app writes them to a durable per-Gateway outbox, shows the queued bubble, then sends them in order after reconnecting. It retains the item until canonical Gateway history confirms delivery and expires it after 48 hours if it remains offline.
Does an offline transcript show live agent state?
No. It is a read-only cache of recent sessions and transcripts. It is useful for orientation, but the Gateway is the source of truth for the current run, approvals, routing, and completed messages.
Why should I not resend a queued message through another channel?
The iOS outbox already retries with an idempotency key. Sending a manual duplicate through another surface can create a second instruction with different timing and context. Reconnect, inspect the fresh session, then decide whether a new message is needed.
What happens when I switch Gateways in the app?
The app stores connection state and cached history per Gateway. Only the focused Gateway receives the iPhone’s capability-bearing node session, so device actions stay attributable to one Gateway at a time.