fix(android): expose exact gateway recovery actions#99414
Conversation
openclaw-barnacle
Bot
added
app: android
Real Gateway + Android emulator evidenceExact head: The matrix used a source Gateway and the exact Play debug APK. No credentials or approval identifiers are visible in these captures. Pending node capability approvalBefore: generic status command. After: this phone's exact safe approval command.
Expired bootstrap codeBefore: generic authentication state. After: structured recovery offers Scan fresh setup code.
Stale stored tokenBefore: generic authentication state. After: structured recovery offers Edit connection.
Recovery scannerThe action launched Google Code Scanner from 
Physical-device coverage remains the only visual proof gap. |
Land-ready verificationExact head: Best-fix review: the Gateway projects a pending approval request ID only to the signed device reading its own node. Android owns one closed approval state, validates IDs before rendering a shell command, expires gateway-local IDs, and routes structured authentication failures to the recovery action that can resolve them. This avoids broad operator-pairing privilege and avoids parallel nullable approval fields. Fresh autoreview: clean, no accepted/actionable findings, confidence 0.90. Local exact-head proof:
Broad repository proof:
Live proof:
Known proof gap: no physical Android device was available. No other known blockers remain. |
|
Merged via squash.
|
* fix(android): expose exact gateway recovery actions * fix(android): keep auth recovery actionable * fix(android): cover terminal gateway auth states * fix(android): keep recovery commands current * fix(android): reset gateway-scoped recovery state * fix(android): keep auth rate limits terminal * fix(android): expire approval ids before refresh * chore(i18n): refresh Android recovery inventory
1 participant
Closes #98046
Closes #98045
AI-assisted: yes. Sanitized transcript logs were not included.
What Problem This Solves
Android Gateway Recovery collapsed stale credentials, expired setup codes, and pending node capability approval into generic status and retry actions. Even when the Gateway knew the pending node request ID, a read-scoped Android client could not display the exact safe approval command.
Why This Change Was Made
The Gateway now includes a pending node request ID only when a signed read-scoped client is reading its own device-backed node. Pending capability declarations and every other node's request ID remain redacted.
Android carries the current phone's capability approval state and optional request ID as one closed value. Onboarding and Nodes & Devices share one command mapper, so a safe request ID produces an exact
openclaw nodes approve <id>command and malformed or unavailable IDs fall back toopenclaw nodes status.Exact approval IDs are gateway-local and short-lived. Android clears them when the target changes, ages cached commands to the status fallback, and refreshes
node.listwhile approval remains pending.Structured connection problems now select the recovery action that can resolve them: an expired bootstrap token scans a fresh setup code, stale client credentials edit the connection, Gateway-host auth configuration stays on an explicit retry path, and transient failures remain retryable. Terminal structured auth advice pauses automatic reconnect so the recovery UI is not immediately overwritten.
User Impact
Android users can distinguish the three common recovery paths and act directly. Pending approval shows a selectable exact host command, expired setup codes lead to a fresh scan, and stale stored authentication leads to connection editing instead of another ineffective retry.
Evidence
node.listandnode.describe.src/gateway/server.node-pairing-authz.test.ts.Authentication neededwithScan fresh setup code;Authentication neededwithEdit connection;Screenshots are attached in the PR comments, not committed to the repository. No physical Android device was available.