BWorlds CLI
Guides

Fix in the repository

Clone, reproduce locally on the Build's seed, and push a fix through short-lived, repository-scoped access.

Command JSON

When the Builder connected their GitHub repository, the CLI works on it for you with a short-lived credential scoped to that one repository. During normal CLI use, the credential stays out of saved Git configuration and command output.

Clone

bworlds repo clone storefront
Cloning storefront into /tmp/bworlds-cli-storefront...
Repo cloned to /tmp/bworlds-cli-storefront

The clone is a temporary directory the CLI manages. Work there, or point your coding agent at it. Pull the latest changes later with bworlds repo refresh storefront. Before fetching, the CLI checks that the remote still matches the repository the server authorized.

Reproduce locally on the Build's data

Many production problems only show with data shaped like production. For Supabase-based Builds, the CLI brings up a local Supabase instance seeded with the Build's shared fixture:

bworlds repo local-setup storefront
Local instance ready for storefront:
  API:     http://127.0.0.1:54321
  Studio:  http://127.0.0.1:54323
  Users:   admin@local.test, user@local.test, user2@local.test (password: demo1234)
  Env:     /tmp/bworlds-cli-storefront/.env.local

When done: bworlds repo local-teardown storefront

It needs git, the Supabase CLI, and psql on your machine, and a supabase/config.toml in the repository. When no seed has been stored for the Build, the local users are created and no data is seeded. local-teardown stops the instance and restores the files setup touched, so the clone is clean for pushing.

Push under your name

bworlds repo push storefront --message "fix(checkout): surface /api/leads failures" --confirm
Pushed changes for storefront

The CLI stages, commits, and pushes, requesting write access for this one operation. When it creates a new commit, that commit is authored by the BWorlds GitHub App and carries your BWorlds handle and identity in trailers. Commit hooks run without the credential in their environment, and the final push skips pre-push hooks for the same reason. Run your own pre-push checks before the command.

If the push fails after the local commit exists, rerun the same command with --confirm. The CLI detects the pending commit and pushes it without committing twice. It preserves that existing commit's metadata, so the actor trailers are guaranteed only when the CLI created the commit. Using a repository credential directly is outside the CLI's attribution guarantees.

Clean up

bworlds repo clean storefront --confirm

This removes only the CLI-managed clone. Your Dossier workspace and credentials are untouched.

Boundaries

  • The CLI attaches to no other folder. Use its clone.
  • The credential lives in the process only. It never lands in remote.origin.url, Git config, or output.
  • --confirm is the CLI's local safety check. The server separately authorizes issuance of the repository credential from your identity and current Workspace access.
  • Keep Git tracing off (GIT_TRACE, GIT_TRACE_CURL, GIT_CURL_VERBOSE) around these commands.
  • Repository operations cost no tokens. They change the Builder's repository, so get their authorization before repo push.

On this page