Skip to main content

​
Agent run failed with a storage error

An error naming the Gateway state database identifies a storage failure observed during the run. The chat banner, recorded assistant error, and embedded_run_agent_end log show the same diagnosis. Provider response bodies remain redacted. A transcript writer ownership error means the run lost its session write claim. Retry in the current session and inspect Gateway logs if it recurs. Storage failures do not trigger provider credential rotation or automatic replay of the run. Use openclaw logs --follow to correlate the run with storage activity. SQLite can contend between connections or worker threads in one Gateway process; seeing only one process with the database open does not rule out contention. See database concurrency notes. Avoid full database compaction while runs are active.

​
No replies

If channels are up but nothing answers, check routing and policy before reconnecting anything.
Look for:
  • Pairing pending for DM senders.
  • Group mention gating (requireMention, mentionPatterns).
  • Channel/group allowlist mismatches.
Common signatures:
  • drop guild message (mention required → group message ignored until mention.
  • pairing request → sender needs approval.
  • blocked / allowlist → sender/channel was filtered by policy.
Related:

​
Dashboard control UI connectivity

When the dashboard/control UI will not connect, validate URL, auth mode, and secure context assumptions.
Look for:
  • Correct probe URL and dashboard URL.
  • Auth mode/token mismatch between client and gateway.
  • HTTP usage where device identity is required.
If a local browser cannot connect to 127.0.0.1:18789 after an update, first recover the local Gateway service and confirm it is serving the dashboard:
If curl returns OpenClaw HTML, the Gateway is working and the remaining issue is likely browser cache, an old deep link, or stale tab state. Open http://127.0.0.1:18789 directly and navigate from the dashboard. If restart does not leave the service running, run openclaw gateway start and recheck openclaw gateway status.
  • device identity required → non-secure context or missing device auth.
  • origin not allowed → browser Origin is not in gateway.controlUi.allowedOrigins (or you are connecting from a non-loopback browser origin without an explicit allowlist).
  • device nonce required / device nonce mismatch → client is not completing the challenge-based device auth flow (connect.challenge + device.nonce).
  • device signature invalid / device signature expired → client signed the wrong payload (or stale timestamp) for the current handshake.
  • AUTH_TOKEN_MISMATCH with canRetryWithDeviceToken=true → client can do one trusted retry with cached device token.
  • That cached-token retry reuses the cached scope set stored with the paired device token. Explicit deviceToken / explicit scopes callers keep their requested scope set instead.
  • AUTH_SCOPE_MISMATCH → the device token was recognized, but its approved scopes do not cover this connect request; re-pair or approve the requested scope contract instead of rotating a shared gateway token.
  • Outside that retry path, connect auth precedence is explicit shared token/password first, then explicit deviceToken, then stored device token, then bootstrap token.
  • On the async Tailscale Serve Control UI path, failed attempts for the same {scope, ip} are serialized before the limiter records the failure. Two bad concurrent retries from the same client can therefore surface retry later on the second attempt instead of two plain mismatches.
  • too many failed authentication attempts (retry later) from a browser-origin loopback client → repeated failures from that same normalized Origin are locked out temporarily; another localhost origin uses a separate bucket.
  • Repeated unauthorized after that retry → shared token/device token drift; refresh token config and re-approve/rotate device token if needed.
  • gateway connect failed: → wrong host/port/url target.

​
Auth detail codes quick map

Use error.details.code from the failed connect response to pick the next action:
Direct loopback backend RPCs authenticated with the shared gateway token/password should not depend on the CLI’s paired-device scope baseline. If subagents or other internal calls still fail with scope-upgrade, verify the caller is using client.id: "gateway-client" and client.mode: "backend" and is not forcing an explicit deviceIdentity or device token.
Device auth v2 migration check:
If logs show nonce/signature errors, update the connecting client and verify it:
1

Wait for connect.challenge

Client waits for the gateway-issued connect.challenge.
2

Sign the payload

Client signs the challenge-bound payload.
3

Send the device nonce

Client sends connect.params.device.nonce with the same challenge nonce.
If openclaw devices rotate / revoke / remove is denied unexpectedly:
  • Paired-device token sessions can manage only their own device unless the caller also has operator.admin.
  • openclaw devices rotate --scope ... can only request operator scopes that the caller session already holds.
Related: