# Agent replies and Control UI > Storage errors, missing replies, and dashboard or Control UI connectivity and auth codes - 网址：https://funcoding.ai/agents/openclaw/gateway/troubleshooting/agent-replies-and-control-ui/ - 来源：OpenClaw 官方文档原文（英文），MIT 许可，同步于 2026-10-11 - 官方原文：https://docs.openclaw.ai/zh-CN/gateway/troubleshooting/agent-replies-and-control-ui --- ## 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. | SQLite message | Next step | | -------------------------------------------------- | -------------------------------------------------------------------------------------------------------------- | | `database is locked` or `database table is locked` | Retry. If it repeats, check Gateway logs and concurrent storage maintenance. | | `database or disk is full` | Free disk space on the Gateway host, then retry. | | `attempt to write a readonly database` | Check the Gateway service user's storage permissions and filesystem mount mode. | | `disk I/O error` | Check storage health and filesystem access before retrying. This message alone does not prove disk exhaustion. | 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](https://funcoding.ai/agents/openclaw/reference/database-schemas/#integrity-checks). Avoid full database compaction while runs are active. ## Provider rejected the request A reply beginning with `LLM request rejected:` includes the provider's request-validation message. OpenClaw redacts credentials, bounds the diagnostic, and displays it as literal text rather than exposing the full response body. Known context, token-limit, and storage failures retain their specific recovery guidance. For `Invalid service_tier argument`, check the selected model and speed setting. A provider or account supporting Fast or Ultrafast does not mean every model supports that tier. Retry with Standard (`/fast off`) or select a model that supports the requested tier. This error alone does not mean the conversation is corrupt. See [OpenAI Fast mode](https://funcoding.ai/agents/openclaw/providers/openai/advanced/#fast-mode). ## Connection to the AI service failed If a reply says OpenClaw could not connect to the AI service, check the provider connection. For a local model, confirm that its server is running and reachable at the configured URL. A server that stops during a turn can leave completed work in the conversation; check those results before retrying. Use `openclaw logs --follow` for connection diagnostics. ## Unreadable conversation history If a reply says OpenClaw could not read the conversation's history, ask the Gateway operator to try `openclaw doctor --fix` on the host and profile that own the session. This notice also appears for unmentioned group turns when silent replies are allowed. Doctor can restore a missing header when the stored transcript entries are already canonical. It does not repair every malformed or unsupported history. If the error persists, preserve the state and contact support with the Gateway logs; the history may need migration or recovery from a backup. Repeated `/new` or `/compact` commands do not repair a transcript that cannot be loaded. See [Doctor's session repairs](https://funcoding.ai/agents/openclaw/gateway/doctor/state-and-sessions/) and [running Doctor](https://funcoding.ai/agents/openclaw/gateway/doctor/running/). ## No replies If channels are up but nothing answers, check routing and policy before reconnecting anything. ```bash openclaw status openclaw channels status --probe openclaw pairing list --channel [--account ] openclaw config get channels openclaw logs --follow ``` 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: - [Channel troubleshooting](https://funcoding.ai/agents/openclaw/channels/troubleshooting/) - [Groups](https://funcoding.ai/agents/openclaw/channels/groups/) - [Pairing](https://funcoding.ai/agents/openclaw/channels/pairing/) If a shared model catalog worker exits and its automatic runtime replacement fails, opening the model picker, preparing a chat, or sending a new message can check the failed runtime again without restarting the Gateway. The picker shows **Loading models…** while checking, then returns to **Models unavailable** if preparation still fails. Repeated foreground checks have a short cooldown. Cron and Heartbeat get one check per failure episode; later scheduled runs do not keep rebuilding a runtime that remains unavailable. Existing messages and tasks are not replayed. This recovery still waits for earlier preparation work to settle. A preparation that never finishes, unrelated configuration errors, and Gateway shutdown require their own diagnosis; a model check does not bypass those lifecycle boundaries. ## Dashboard control UI connectivity When the dashboard/control UI will not connect, validate its URL, authentication, and device identity. ```bash openclaw gateway status openclaw status openclaw logs --follow openclaw doctor openclaw gateway status --json ``` Look for: - Correct check URL and dashboard URL. - Auth mode/token mismatch between client and gateway. - Clients that connect without the required device identity. The current Control UI can create and sign identity over plain HTTP; see [Insecure HTTP](https://funcoding.ai/agents/openclaw/web/control-ui/#insecure-http). 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: ```bash openclaw gateway restart lsof -i :18789 curl http://127.0.0.1:18789 ``` 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`.
Connect / auth signatures - `device identity required` → the client did not provide the identity required by its role and auth policy. Plain HTTP alone is not the cause. In token/password mode, the Control UI still requires browser device identity; the shared secret does not replace it. - `origin not allowed` → the browser `Origin` is not allowed and is not a private same-origin load. Private same-origin loads, including private LAN/Tailscale addresses and `.local` or `.ts.net` hosts, do not need an allowlist entry. Public or cross-origin browser deployments need an entry in `gateway.controlUi.allowedOrigins`. - `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: | Detail code | Meaning | Recommended action | | ---------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `AUTH_TOKEN_MISSING` | Client did not send a required shared token. | On the Gateway host, run `openclaw gateway auth-token --show` in an interactive terminal, paste the output into the client, and retry. | | `AUTH_TOKEN_MISMATCH` | Shared token did not match gateway auth token. | If `canRetryWithDeviceToken=true`, allow one trusted retry. Cached-token retries reuse stored approved scopes; explicit `deviceToken` / `scopes` callers keep requested scopes. If still failing, run the [token drift recovery checklist](https://funcoding.ai/agents/openclaw/cli/devices/#token-drift-recovery-checklist). | | `AUTH_DEVICE_TOKEN_MISMATCH` | Cached per-device token is stale or revoked. | Rotate/re-approve device token using [devices CLI](https://funcoding.ai/agents/openclaw/cli/devices/), then reconnect. | | `AUTH_SCOPE_MISMATCH` | Device token is valid, but its approved role/scopes do not cover this connect request. | Re-pair the device or approve the requested scope contract; do not treat this as shared-token drift. | | `PAIRING_REQUIRED` | Device identity needs approval. Check `error.details.reason` for `not-paired`, `scope-upgrade`, `role-upgrade`, or `metadata-upgrade`, and use `requestId` / `remediationHint` when present. | Approve pending request: `openclaw devices list` then `openclaw devices approve `. Scope/role upgrades use the same flow after you review the requested access. |
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: ```bash openclaw --version openclaw doctor openclaw gateway status ``` If logs show nonce/signature errors, update the connecting client and verify it: **Wait for connect.challenge** Client waits for the gateway-issued `connect.challenge`. **Sign the payload** Client signs the challenge-bound payload. **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: - [Configuration](https://funcoding.ai/agents/openclaw/gateway/configuration/) (gateway auth modes) - [Control UI](https://funcoding.ai/agents/openclaw/web/control-ui/) - [Gateway protocol auth](https://funcoding.ai/agents/openclaw/gateway/protocol/auth/) — the wire contract behind `AUTH_TOKEN_MISMATCH` and `AUTH_SCOPE_MISMATCH` - [Devices](https://funcoding.ai/agents/openclaw/cli/devices/) - [Remote access](https://funcoding.ai/agents/openclaw/gateway/remote/) - [Trusted proxy auth](https://funcoding.ai/agents/openclaw/gateway/trusted-proxy-auth/)