Skip to content
Guides

ClawHub namespace claims

When an owner handle or a package scope belongs to someone else, what evidence settles it, and the one thing you must never put in the issue

6 min read

Every registry eventually has to answer the question of who owns a name. ClawHub answers it with a dedicated public process, and the first useful thing to know is that it is not the report button and not the account appeal form. Those are different doors for different problems, and a namespace dispute filed through either of them is in the wrong queue.

When a claim is the right door

  • An org handle that matches your GitHub org, project, company or community but is held by someone else.
  • A package scope that should only ever publish under the matching ClawHub owner.
  • A skill slug or plugin package name that appears to impersonate a project, or a brand, trademark, rename or package-history dispute.
  • A deleted, inactive or unreachable owner sitting on a namespace and blocking the person who should hold it.
Use this path for public, non-sensitive ownership review. Do not use in-product reports or the account appeal form for namespace claims.

Try to fix it yourself first

Before filing anything, confirm you are publishing as the owner that matches the namespace, because for scoped plugin packages the scope and the publishing owner have to agree. If you can already manage the current owner, the fix is in your own hands: publish, rename, transfer, hide or delete the affected resource directly. A claim is for the case where you cannot manage the current owner, or where staff genuinely need to resolve a dispute between two parties.

Evidence that actually settles it

  • GitHub org, repository, release or maintainer history, and official project documentation that names the namespace.
  • Domain or official email-domain proof, or control of the matching scope on npm, PyPI, crates.io or another package registry.
  • Trademark, brand or project-ownership evidence that is safe to discuss in public, plus links to the disputed owner, skill, plugin or package.

The instruction that does the most work is the quiet one: explain what each link proves. Staff should be able to follow the relationship without private credentials and without guessing, and a claim that is a bare list of URLs makes them do that guessing. For the surrounding policy, see ClawHub moderation and account standing and What ClawHub checks before publishing.

What must never go in

The claim form is a public issue, which makes one rule absolute: no secrets, no private documents, no private legal files, no personal identity documents, no API tokens and no DNS challenge tokens. If the only proof you hold is sensitive, the claim is not the place for it. And if the listing is unsafe, malicious or misleading beyond the ownership question, that part follows the moderation or security path instead, because the claim form is for ownership review and not for emergency vulnerability disclosure. See Reporting a ClawHub vulnerability and How ClawHub works.

On Diali

Diali hosts OpenClaw and publishes nothing to the registry on your behalf, so a namespace you claim stays yours. Each customer runs their own assistant, 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 namespace dispute is a claim, not a report and not an appeal.
  • Say what each piece of evidence proves.
  • It is a public issue: nothing secret goes in it.
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.