Set up with an AI agent
Tell a coding agent such as Claude Code to set up PrivateCrates for your organisation and publish your
crates. It does the work with the cargo privatecrates CLI and your own gh login, and
stops only where GitHub insists on a person.
What the agent does, and what needs you
You need to be an admin of the GitHub organisation, with the GitHub CLI signed in (gh auth status). Four moments need you: approving the agent’s sign-in, installing each of the two GitHub Apps, and
accepting the private preview terms on behalf of your organisation.
| Step | Who | How |
|---|---|---|
| Sign in to PrivateCrates | Agent, you approve | The agent runs cargo privatecrates login and gives you a code and a link. You approve the sign-in on GitHub, once. |
| Install the reader App | You | GitHub has no API to install an App. The agent gives you the link; you install it on the organisation. |
| Create the storage repository | Agent | gh repo create, with your own gh login, as a private repository named crates-store. |
| Turn on immutable releases | Agent | gh api, with your rights. Our Apps never get administration rights. |
| Install the storage App on that repository | You | The agent gives you the link, pre-selected for your organisation; you choose that one repository. |
| Accept the private preview terms | You | The agent gives you the link to the terms and waits. You read them and tell it you accept, on behalf of your organisation. It never accepts for you. |
| Choose the registry name | Agent | cargo privatecrates setup --slug --accept-terms private-preview-2026-09-28-2, only after you have accepted. The service saves privatecrates.toml in the storage repository. |
| Configure each crate repository | Agent | cargo privatecrates init, then a pull request. You review and merge. |
| Publish a first version | Agent | It pushes a tag; GitHub Actions publishes. cargo privatecrates doctor confirms the result. |
The prompts
The account page gives you both prompts filled in for your organisation, with its
install links, under “Set up with your AI agent”. The examples below are for acme. Each prompt
points the agent at /llms.txt, which describes the whole flow
for agents.
1. Set up the registry
The agent goes through the checklist in order, skipping what is done, and hands you a link at each step that
needs you. It checks its progress with cargo privatecrates setup acme --json.
Set up PrivateCrates, our private Cargo registry, for the GitHub organisation acme.
First read https://privatecrates.dev/llms.txt: it describes the set-up flow and the cargo privatecrates CLI.
Registry name: acme, served at https://acme.privatecrates.dev
Already done: the plan is settled.
Steps:
1. Install the CLI if it is missing: cargo binstall cargo-privatecrates (or, without cargo-binstall, cargo install cargo-privatecrates --locked)
2. Sign in: cargo privatecrates login. It prints a code and a GitHub link; give me both and wait while I approve.
3. Stop and ask me to install the PrivateCrates reader App on acme, on all repositories or on those that own crates: https://github.com/apps/privatecrates-reader/installations/new
4. Create the storage repository with my gh login, and turn on immutable releases:
gh repo create acme/crates-store --private
gh api -X PUT repos/acme/crates-store/immutable-releases
5. Stop and ask me to install the PrivateCrates storage App on acme/crates-store only ("Only select repositories"): https://github.com/apps/privatecrates-storage/installations/new
6. Show me the terms, https://privatecrates.dev/legal/terms, and ask me to read them and accept them on behalf of acme. Wait until I say I accept. Never accept them for me, and do not go on if I decline. Then ask me who may publish crates: GitHub Actions only (recommended: every version is built from a commit, with provenance signed by GitHub), or also developers' own machines with cargo publish (no provenance). Only then choose the registry name: cargo privatecrates setup acme --slug acme --accept-terms private-preview-2026-09-28-2, adding --allow-manual-publish only if I chose developers' machines
7. Confirm: cargo privatecrates setup acme --json must report every step as done. Then tell me the registry URL.
Rules:
- Use my own gh login for repository administration (check it with gh auth status). Never ask me for a personal access token or any other GitHub token, and never create one.
- Where GitHub needs a person, stop: give me the link, say what to choose there, and wait until I say it is done. Then check with cargo privatecrates setup acme --json.
- Change nothing in acme beyond what these steps need.
- Never accept the PrivateCrates terms on my behalf, and never pass --accept-terms until I have said I accept.2. Configure and publish crates
Once the registry is live, this prompt configures each crate repository you choose, opens pull requests for you to review, and publishes a first version from CI.
Configure the Rust crates in the GitHub organisation acme to use and publish to our PrivateCrates registry, acme (https://acme.privatecrates.dev).
First read https://privatecrates.dev/llms.txt: it describes the cargo privatecrates CLI.
Steps:
1. Install the CLI if it is missing: cargo binstall cargo-privatecrates (or, without cargo-binstall, cargo install cargo-privatecrates --locked)
2. List acme's repositories that contain Rust crates (gh repo list acme --limit 500, then look for Cargo.toml). Show me the list and ask which crates to publish before changing anything.
3. In each chosen repository, on a new branch: run cargo privatecrates init --registry acme --dry-run and show me the plan, then cargo privatecrates init --registry acme --yes, which also sets publish = ["acme"] on each crate; set publish = false on any crate that should not be published, commit, and open a pull request with gh pr create. Do not merge it: I review and merge.
4. Once a pull request is merged, publish a first version from CI by pushing a tag that matches the crate's version, e.g. git tag v0.1.0 && git push origin v0.1.0; in a workspace, tag one crate with <crate>-v<version> (e.g. story_engine-v0.1.0), since v<version> publishes every crate. The publish workflow runs in GitHub Actions; follow it with gh run watch.
5. Run cargo privatecrates doctor in each repository, and fix or report anything it flags.
Rules:
- Use my own gh login for repository administration (check it with gh auth status). Never ask me for a personal access token or any other GitHub token, and never create one.
- Where GitHub needs a person, stop: give me the link, say what to choose there, and wait until I say it is done. Then check with cargo privatecrates doctor.
- Change nothing in acme beyond what these steps need.
- Never publish from this machine and never add secrets to CI: publishing uses GitHub Actions' OIDC token.The cargo privatecrates CLI
An open-source Cargo subcommand for setting up a registry and configuring repositories. Agents do better with one deterministic command than with a recipe, and so do people.
cargo binstall cargo-privatecrates # prebuilt, checksummed and attested
# without cargo-binstall, it builds from source:
cargo install cargo-privatecrates --lockedcargo privatecrates login
cargo privatecrates logout
cargo privatecrates setup <org> [--slug <name> --accept-terms <version> [--allow-manual-publish]] [--json]
cargo privatecrates terms <org> --accept <version>
cargo privatecrates init --registry <name> [--dry-run | --yes] [--no-workflow] [--domain <domain> | --url <url>]
cargo privatecrates doctor [--json]Every command talks to privatecrates.dev. For another environment, add --domain with its domain
to each command.
login and logout
Signs in with GitHub’s device flow for the reader App, the same sign-in and token store as the credential provider. The token can read repository metadata and nothing else.
# Prints a code and a GitHub link; approve it in the browser
cargo privatecrates login
# Forget the stored token
cargo privatecrates logoutsetup
Prints the organisation’s set-up checklist, each step’s status, and a link where a person must act. --slug saves the registry name, and needs --accept-terms with the version of the
terms an admin has read and accepted; without it, the command prints the terms’ link and the exact flag to
add, and stops. --json prints the checklist for agents and scripts. For a registry created before the terms, cargo privatecrates terms records an admin’s acceptance.
# The checklist: each step's status, with a link where a person must act
cargo privatecrates setup acme
# Choose the registry name (once both Apps are installed), after an admin has read
# and accepted the terms at https://privatecrates.dev/legal/terms on behalf of acme
cargo privatecrates setup acme --slug acme --accept-terms private-preview-2026-09-28-2
# An existing registry whose admin has not accepted the current terms yet
cargo privatecrates terms acme --accept private-preview-2026-09-28-2
# The same checklist as JSON, for agents and scripts
cargo privatecrates setup acme --jsonThe storage repository is created with your own GitHub login, not ours:
gh repo create acme/crates-store --private
gh api -X PUT repos/acme/crates-store/immutable-releasesinit
Run in a crate repository or workspace. It adds the registry to .cargo/config.toml, keeping its
formatting; sets package.repository from the git remote where it is missing (in [workspace.package] for workspaces); and writes .github/workflows/publish.yml.
Running it again changes nothing, and it prints what it changed. --url gives the registry’s full
URL instead of its name’s default.
# In a crate repository or workspace
git switch -c privatecrates
cargo privatecrates init --registry acme
git add -A && git commit -m "Publish to the acme registry"
gh pr create --filldoctor
Checks that the credential provider is installed and configured, the registry answers, package.repository matches the git remote, and the publish workflow has id-token: write, and that publish is restricted to the registry. Once a version is
published, it checks that it is in the registry’s index. Immutable releases and provenance are checked by the verifier, which runs on the storage repository.
cargo privatecrates doctor
# For agents and scripts
cargo privatecrates doctor --jsonSecurity
- No broad tokens. Nothing in this flow needs a personal access token. If an agent asks for one, or offers to create one, say no.
- Administration stays with you. Creating the storage repository and turning on immutable
releases use your own
ghlogin, so the PrivateCrates Apps keep their narrow permissions: metadata read for the reader App, and contents write on one repository for the storage App. - The agent’s own token is narrow.
cargo privatecrates logingets a reader App token that can read repository metadata and nothing else, valid for 8 hours.cargo privatecrates logoutdeletes it from the machine, and you can revoke it at once on GitHub under Settings → Applications → Authorized GitHub Apps. - You accept the terms, not the agent. Accepting binds your organisation, so only you can do it, after reading them.
- You review every change. The agent opens pull requests; you merge them. CI publishes with GitHub Actions’ OIDC token, so no secret is added to any repository.
Where the agent stops
At each step that needs you, the agent gives you a link and waits. Open it, do what it says on GitHub, then tell the agent you are done; it confirms the step before going on.
The terms are yours to accept. The agent shows you the link to the private preview terms and passes --accept-terms only after you say you accept. It must never accept them for you.