GitHub-Backed ClawHub Installs Make Skills Easier to Ship — and Put Provenance Back on the Critical Path

GitHub-backed ClawHub installs are the kind of feature that looks like convenience and quietly becomes infrastructure. Builders already keep skills, recipes, deployment snippets, and examples in GitHub repositories. Registries want to index those artifacts without forcing every author through bespoke packaging. Users want one command. That triangle is reasonable — and it is exactly why provenance has to become a first-class product surface, not a footnote after the download completes.

PR #90478, opened June 4 at 23:18 UTC, adds resolver-based unversioned ClawHub skill installs. The new path resolves installs through /api/v1/skills/:slug/install, including GitHub-backed resolutions that fetch a pinned repo archive from GitHub codeload and copy only the resolved skill path into the local skills directory. It also adds authenticated install telemetry back to ClawHub and preserves the operator install-policy checks introduced by PR #89516.

The headline should not be “OpenClaw can install skills from GitHub.” That is table stakes for a developer ecosystem. The headline is that OpenClaw is trying to make “install from GitHub” mean something narrower and reviewable: a specific skill path from a specific commit, mediated by registry metadata and local operator policy. That is the minimum shape a skill supply chain needs before it can be trusted by people who do not personally read every line of every repo before lunch.

A skill install is a trust decision with a nicer CLI

The PR is substantial: GitHub’s file API showed 23 changed files and a +925/-235 diff, including src/infra/clawhub.ts, src/skills/lifecycle/clawhub.ts, ClawHub install E2E tests, heartbeat parsing tests, and supporting E2E helpers. The author listed verification through pnpm tsgo:core, pnpm tsgo:test:src, targeted Vitest for the ClawHub lifecycle tests, and a ClawHub install E2E run.

The manual proof posted later is the most useful detail. The author ran a real OpenClaw CLI process against a temporary local ClawHub install resolver, downloaded a real GitHub codeload archive from NVIDIA/skills, pinned source commit bb0436faf7c9c5270f2dbc3d30c39379e5e2305b, and installed only skills/aiq-deploy. Those specifics matter. “NVIDIA/skills” is a repository. “skills/aiq-deploy at commit bb0436…” is an artifact an operator can reason about, cache, audit, and reproduce.

The path-scoped copy is not cosmetic. Repositories contain CI files, scripts, examples, test fixtures, build artifacts, and the occasional human mistake. A broad “install this repo” primitive gives the agent ecosystem too much ambient material and too little review boundary. A skill path from a pinned commit still does not prove the content is safe, but it makes the object of review stable. That is the difference between supply-chain theater and supply-chain mechanics.

ClawSweeper’s review found exactly the kind of sharp edge this feature invites. It flagged one new default resolver endpoint dependency and two environment variables that can redirect codeload downloads: OPENCLAW_CLAWHUB_GITHUB_CODELOAD_BASE_URL and CLAWHUB_GITHUB_CODELOAD_BASE_URL. It also found a rollout risk: a live check of the public resolver endpoint returned 404 while existing detail/download endpoints still worked for a real skill. That is not a philosophical objection. It is operational review doing its job: new source types need fallback behavior, scoped credentials, and a failure mode that does not break the old path prematurely.

The token-leak finding is the part everyone should copy

The most important security detail was not the resolver endpoint. It was credential scoping. ClawSweeper identified that ambient ClawHub tokens must not be sent to off-registry archive URLs. Follow-up comments say the finding was fixed: GitHub-backed archive URLs no longer receive OPENCLAW_CLAWHUB_TOKEN when the resolver returns an absolute non-ClawHub URL, with a regression test proving codeload requests are made without an Authorization header.

That fix is boring in exactly the right way. Registry auth tokens are not generic download credentials. A resolver may tell the client where to fetch an archive, but that does not mean the registry’s authorization should follow the request to a different host. Agent tooling has a habit of turning “just fetch the archive” into ambient authority. The safer contract is host-scoped and purpose-scoped: use ClawHub credentials for ClawHub, use GitHub access only when explicitly configured for GitHub, and attach no credential by default to a public codeload URL.

This matters because skills are not passive packages. A skill teaches an agent how to act. It may include instructions, tool usage patterns, operational assumptions, and workflows that later influence privileged behavior. If plugin systems are supply chains, skill systems are supply chains with a behavioral payload. Provenance needs to cover not just where bytes came from, but what authority the installed content can exercise once the agent reads it.

Operators should watch three things before enabling GitHub-backed skill installs broadly. First, resolver availability and compatibility: a 404 on the new resolver should not strand users if older detail/download paths still work. Second, codeload base URL overrides: those environment variables are powerful enough to deserve the same review as registry endpoints or update mirrors, especially in CI and shared workstations. Third, install-policy context: the prompt shown to operators should include the resolver slug, registry metadata, GitHub owner/repo, commit SHA, skill path, archive URL, and credential behavior. If the policy decision lacks those facts, it is not informed consent; it is a vibes checkbox.

For builders publishing skills, the best practice is now obvious. Put each installable skill in a clear subdirectory. Treat commits as release artifacts. Avoid requiring broad repository context at runtime. Document what the skill does, which tools it expects, and what data it may touch. If the registry can only safely install a path from a commit, design your repo so that path is enough.

PR #90478 is a good usability move, but the win is not “install from GitHub.” The win is “install this exact skill path from this exact commit without leaking registry credentials to the wrong host.” That is the bar agent ecosystems should copy before registry convenience becomes another supply-chain incident with better branding.

Sources: OpenClaw PR #90478, OpenClaw PR #89516, ClawHub, OpenClaw skills documentation