samsung app openclaw not working

[dry fern]

What's confirmed working:

• Gateway is up, LAN bind is reachable
• Device can establish a WS connection and make API calls (commands.list, models.list succeed)
• QR pairing auto-approves correctly server-side
• Main agent session is active (agent:main:main, 1m ago)

Confirmed problems:

1. Bootstrap token loop — Every QR scan generates a new one-time token, invalidating all previous ones. The app cached a
   stale token from an earlier scan and kept hammering the gateway with it (bootstrap_token_invalid repeating for ~30 min).
   After force-stop the device stopped connecting entirely — it lost all credentials and now has nothing.
2. acp.defaultAgent = "claude" is not a real agent — The configured agents are main, rachel, saul, andrew, scott, samuel,
   carmen, huhu, lyra, james. There is no agent named "claude" or "codex". Whatever the mobile app checks to determine
   "operator online/offline", it routes through ACP to "claude" — which doesn't exist.

[marsh spear]

To help others find answers, you can mark your question as solved via Right click solution message -> Apps -> ✅ Mark Solution

[glossy spear]

Nice debugging, and I think you caught the important part.

I’m pretty sure issue #1 is the real blocker.

What I checked in current docs/code:

• Setup QR codes use a short-lived bootstrap token, not a durable credential, docs: https://docs.openclaw.ai/cli/qr https://docs.openclaw.ai/channels/pairing
• Reconnect auth is supposed to prefer stored device tokens before bootstrap, docs: https://docs.openclaw.ai/gateway/protocol
• iOS explicitly clears the cached bootstrap token after first successful bootstrap connect
• Android currently looks worse here: on bootstrap-auth connects it only persists bootstrap handoff tokens on trusted transport (wss:// or loopback), and I do not see the same “clear spent bootstrap token after success” path there

So on Android + raw LAN ws://, the failure mode you described makes sense:

1. first QR scan works
2. bootstrap token gets spent
3. app keeps/reuses stale bootstrap token
4. after force-stop, there is no durable stored token to fall back to
5. gateway returns bootstrap_token_invalid forever until a fresh pairing

On #2, I’d be a bit careful: acp.defaultAgent: "claude" is definitely bad config if ACP is enabled, and it should be changed to a real ACP harness id or removed. Docs: https://docs.openclaw.ai/gateway/configuration-reference#acp

But from current mobile code, basic mobile agent/default state appears to come from agents.list / defaultId, not acp.defaultAgent, so I don’t think that explains the bootstrap loop by itself.

My recommendation right now:

• For recovery, use a secure endpoint, wss:// / Tailscale Serve, or save a real shared gateway token/password in the app instead of relying on QR bootstrap over plain LAN ws://
• Also fix acp.defaultAgent, since "claude" is invalid in this setup
• This looks bug-worthy, I’d file it here with your repro and logs: https://github.com/openclaw/openclaw/issues

Please also paste:

• openclaw --version
• Android app version/build

That’ll tell us pretty quickly if you’re hitting current behavior or an already-fixed regression.

[dry fern]

OpenClaw 2026.4.12 (1c0672b), samsung 20264.5

[glossy spear]

Thanks, that helps. You’re not crazy.

I checked current main, and there are already Android follow-up fixes after your 2026.4.12 build that line up almost exactly with this:

• fix(android): delay operator bootstrap reconnect until stored auth
• fix(android): reset auth on new setup codes
• fix(android): prefer stored device auth after pairing

So my read is:

1. the stale/spent bootstrap-token reuse on Android is real
2. rescanning setup codes not fully clearing old auth state was real
3. reconnect preferring bootstrap over stored device auth was real
4. acp.defaultAgent = "claude" is definitely bad config, but probably secondary here

Also, from current mobile code, the app’s basic overview/default-agent path uses health and agents.list, not ACP, so I do not think acp.defaultAgent is the main cause of the bootstrap loop. It should still be fixed, because any ACP path that omits agentId will break.

Best next steps:

• if there’s a newer Samsung/Android build available, I’d try that first
• for a workaround now, use wss:// / Tailscale Serve, or save a real shared token/password in the app instead of bootstrap-only over raw LAN ws://
• clear the app’s pairing/auth state, then rescan a fresh setup code
• set acp.defaultAgent to a real ACP harness id, or remove it if unused

Docs for the intended bootstrap/device-token behavior:
https://docs.openclaw.ai/cli/qr
https://docs.openclaw.ai/gateway/protocol

This looks GitHub-issue worthy if it isn’t already filed:
https://github.com/openclaw/openclaw/issues

If you want, I can help turn your notes into a tight issue report with the likely culprit commits called out.

[dry fern]

Yes. Go ahead and submit on github for me.

[glossy spear]

I can’t open the GitHub issue myself from here, but I can make this easy. Paste this into https://github.com/openclaw/openclaw/issues/new:

Title: Android/Samsung app reuses spent QR bootstrap token on LAN ws://, then loses reconnect auth after force-stop

## Version

- OpenClaw: `2026.4.12 (1c0672b)`
- Samsung app: `20264.5`

## Summary

On the Samsung Android app, QR pairing over raw LAN `ws://` can get stuck reusing a spent bootstrap token.

What I observed:

- each QR/setup-code scan generates a new one-time bootstrap token
- the app cached a stale token from an earlier scan
- it kept reconnecting with that stale token and the gateway logged `bootstrap_token_invalid` repeatedly for ~30 minutes
- after force-stopping the app, it stopped connecting entirely and appeared to have no durable credentials left

There is also a second config-related problem:

- `acp.defaultAgent = "claude"` is set, but `"claude"` is not a real configured agent/harness in this setup
- configured agents are: `main, rachel, saul, andrew, scott, samuel, carmen, huhu, lyra, james`

## What is confirmed working

- Gateway is up
- LAN bind is reachable
- Device can establish a WebSocket connection

- API calls like `commands.list` and `models.list` succeed
- QR pairing auto-approves correctly server-side
- Main agent session is active (`agent:main:main`)

## Confirmed problems

### 1) Bootstrap token loop

- every QR scan creates a new one-time token
- the app kept using a stale token from an earlier scan
- gateway repeatedly returned `bootstrap_token_invalid`
- after force-stop, the app had no usable saved credentials and could no longer reconnect

### 2) Invalid ACP default agent

- `acp.defaultAgent = "claude"` is configured
- there is no configured agent/harness named `"claude"` or `"codex"` in this environment
- something in the mobile app’s operator online/offline path appears to consult ACP and ends up pointing at the nonexistent `"claude"` target

## Repro

1. Run gateway on private LAN `ws://`
2. Pair Samsung app via QR/setup code
3. Auto-approve pairing server-side
4. Scan again / reconnect in a way that rotates the bootstrap token
5. Observe the app continue trying the stale token
6. Observe repeated `bootstrap_token_invalid` in gateway logs
7. Force-stop app
8. Relaunch app
9. Observe that it no longer has working reconnect credentials

## Expected

- after the first successful bootstrap pairing, the app should stop reusing the spent bootstrap token
- reconnect should prefer stored device auth
- rescanning a new setup code should clear or supersede stale auth state
- force-stop should not leave the app without any usable reconnect credentials
- invalid `acp.defaultAgent` should not affect basic mobile online/offline status, or the app should fail clearly

## Actual

- stale bootstrap token is reused
- reconnect loops on `bootstrap_token_invalid`
- after force-stop, the app appears to have no durable auth to reconnect with
- invalid `acp.defaultAgent` may also confuse the operator online/offline path