openclaw - 💡(How to fix) Fix [Bug]: Android app send-button never fires chat.send RPC; messages disappear from UI after optimistic add

Bug type

Behavior bug (incorrect output/state without crash)

Beta release blocker

No

Summary

On the OpenClaw Android app (paired 2026-05-08, OnePlus 11 5G, role=node+operator), pressing the send button in the Chat screen never reaches the gateway. The user sees the message appear briefly via optimistic UI update, then it disappears (<1 s later). Gateway logs across two separate test sessions show 6 send attempts → 0 chat.send calls, while every send-press is correlated with a chat.history poll arriving at the gateway.

The WebSocket connection itself is healthy: health heartbeats and chat.history calls succeed (110-156 ms), so this is not the gateway-side authorization issue fixed in #6767. The problem is purely client-side — either the send-handler is wired to the wrong RPC, or a preflight check aborts before constructing the chat.send payload.

Steps to reproduce

1. Pair the OpenClaw Android app to a gateway running 2026.5.6 (auto-approved, role=node, both node and operator tokens issued).
2. Open the Chat tab; select a session whose canonical key resolves to agent:main:main (in the picker labelled Main).
3. Type any text (test) and press the send button.
4. Observe: spinner on the send button → message appears briefly in the chat → message disappears in <1 s.
5. Tail gateway: journalctl --user -u openclaw-gateway -f | grep -E "⇄ (req|res)".

Expected behavior

A ⇄ req chat.send line appears in the gateway log within ~100 ms of the send press, and the message persists in the chat UI.

Actual behavior

Two separate 3-message test sessions, captured live with a broad WS-traffic tail:

Session 1 — sent "test", "test 2", "test 3" with seconds between:
  23:47:37  ⇄ res ✓ chat.history 156ms conn=514a6ba7…ffb4
  23:48:01  ⇄ res ✓ chat.history 111ms conn=514a6ba7…ffb4
  23:48:18  ⇄ res ✓ chat.history 128ms conn=514a6ba7…ffb4
  (zero chat.send across full window)

Session 2 — sent "1", "2", "test" with seconds between:
  00:05:50.516  ⇄ res ✓ chat.history 109ms conn=514a6ba7…ffb4
  00:05:53.800  ⇄ res ✓ chat.history 110ms conn=514a6ba7…ffb4
  00:05:56.657  ⇄ res ✓ chat.history 111ms conn=514a6ba7…ffb4
  (zero chat.send across full window)

In both sessions:
  - WS health pings continue every 30s (cached=true, ✓)
  - No errorCode / unauthorized / role-mismatch entries on gateway
  - Every send-press correlates with one chat.history call within ~3 s

The 1:1 correlation between send-presses and chat.history polls (00:05:50/53/56 matching three send-presses ~3 s apart) suggests the send button's handler triggers a history-refresh — either the handler is wired to the wrong RPC, or a preflight aborts before issuing chat.send and triggers a history-poll on rollback. The optimistic UI message is then overwritten by the history response (which legitimately does not contain it).

This is the same symptom class as #6767 bug #2 (UI shows then loses the message because chat.history returns a state that doesn't contain the new message), but on the Android side. The gateway-side allowlist fix from #6767 (NODE_CHAT_METHODS includes chat.send) is correctly in place — confirmed by the fact that chat.history succeeds for this same node-role connection.

OpenClaw version

2026.5.6 (commit c97b9f7)

Operating system

Ubuntu 24.04 (gateway), Android (OxygenOS, OnePlus 11 5G client)

Install method

npm (gateway). Android app installed from the official apps/android build.

Model

Not relevant — request never reaches the agent runtime.

Provider / routing chain

Not relevant — request never reaches the gateway.

Additional provider/model setup details

• Network: Android device and gateway VPS on the same Tailscale tailnet; pairing via openclaw qr over Tailscale-routed gateway URL.
• Device tokens (from devices/paired.json):
  • tokens.node.scopes = [] (empty — appears normal for node role)
  • tokens.operator.scopes = ["operator.approvals", "operator.read", "operator.talk.secrets", "operator.write"]
• The same gateway accepts chat.history from this exact connection without issue, so the bug is fully client-side.

Logs, screenshots, and evidence

See "Actual behavior" above. Both test sessions captured with journalctl --user -u openclaw-gateway -f --no-pager | grep -E "⇄ (req|res)|errorCode|unauthorized".

Impact and severity

Renders the Android app unusable as a chat surface against the gateway. Workaround: use Telegram channel or Control UI in mobile browser (both work over the same Tailnet).

Additional information

Possible root causes worth investigating in apps/android:

1. Send-button handler wires to chat.history instead of chat.send (handler swap regression).
2. Send preflight does a session-key/role check that fails silently and aborts the RPC before construction; rollback path issues a chat.history refresh that overwrites the optimistic add.
3. Race condition between optimistic add and history-poll where the history response is committed last and replaces local state (similar to #6767 bug #2 but on the client side instead of the server side).

The gateway-side fix from #6767 is intact (verified by working chat.history from this node-role connection).