Skip to content
Guides

ClawHub troubleshooting

The six failures worth recognising on sight, and the one that is almost never actually your fault

7 min read

Most ClawHub failures are legible once you know which of a handful of shapes you are looking at. What follows is the whole list, in the order you are likely to meet them, with the distinguishing detail for each rather than a generic retry.

Sign-in and authorisation

  • If login sits waiting, open the verification URL the CLI printed, sign in with GitHub and authorise the displayed code. A browser on another device works, because no localhost callback is involved.
  • If the code expires, simply run login again; for unattended use, create an API token in settings and pass it to login directly.
  • A 401 from whoami or publish means sign in again, and if you use a custom config path, check it points at the file holding your current token.
  • A 401 that survives a fresh sign-in usually means the API token was revoked in the web interface, which the CLI cannot know until it tries.
If many users share one egress IP, anonymous IP limits can be hit even when each person only sends a few requests.

The 429 you did not earn

That quote is the failure most worth recognising, because it is the one where your own behaviour is not the cause. Behind a shared office network, a VPN or a CI runner pool, everybody is one IP as far as the anonymous limiter is concerned, and a handful of requests each adds up to a rate limit nobody individually triggered. The fix is to sign in where possible, which moves you to a per-user budget, and otherwise to read the retry headers and wait the reported delay.

Reading the retry information

  • Retry-After gives the seconds to wait, and is the value to prefer when it is present.
  • RateLimit-Limit is the limit applied to that request, and RateLimit-Remaining is your exact remaining budget when the header is there, which on a 429 is zero.
  • RateLimit-Reset or its prefixed twin carries reset timing, and the two are in different units, so read the one you are actually parsing.

A request that fails behind a corporate proxy usually needs no ClawHub-specific fix at all: the CLI honours the standard proxy variables in both their uppercase and lowercase spellings, so exporting the right one is the whole change. For the conventions the headers follow, see The ClawHub API, and for the client that emits these requests, The ClawHub CLI.

Missing from search, or rejected at publish

A skill absent from search is not necessarily gone. Check the exact slug or the owner page, then confirm the release is public and not held by scan or moderation, because a hold hides a listing from search and install surfaces without deleting it. If you own it, sign in and inspect it: owner-visible diagnostics explain scan, upload-gate and moderation state, which a public caller never sees. A publish rejected for missing metadata points back at the frontmatter, where required environment variables and tools have to be declared so both users and scanners can understand the package. See The ClawHub skill format and ClawHub moderation and account standing.

On Diali

On Diali most of these failure modes never reach you, because the assistant is already signed in and already running. Each customer runs their own instance, the runtime configuration is generated from the dashboard and replaced at each release, and state lives on a persistent volume, with daily snapshots and one-click restore available through the Backups add-on (included on Max). See Hosted OpenClaw on Diali for what the hosting includes and Diali pricing for what it costs.

  • A 429 on a shared network is usually not your traffic.
  • Sign in to move from an IP budget to a per-user one.
  • Missing from search often means held, not deleted.
Get started

Stop reading about it, build one

Set up an agent, pick a channel, and have it working inside the app you already keep open.