Authenticating git operations

Every circuit on QubitHub is a real git repository. You can clone it, commit to it, and push back with the git you already have installed — no QubitHub tooling required.

Reading a public circuit needs no credentials. Writing does, and the credential is not your website password.

The one rule

When git prompts you for credentials:

• Password — a QubitHub API key (or a JWT access token).
• Username — ignored. Type anything, or leave it blank.

This is the same shape as a GitHub personal access token. Your login password will never work, and the error you get if you try it (Authentication failed) does not say why.

Blank usernames work

The username is a label QubitHub never reads, so anything and an empty field authenticate identically. Git Credential Manager and some GUI clients make an empty username awkward to submit — if yours does, type any word and move on.

Create a key

1. Go to Dashboard → API Keys.
2. Create new key, give it a name (laptop, ci), keep the default scopes.
3. Copy the key — it starts with qh_ and is shown once.

You do not need an organisation. Personal keys work for every circuit you own.

Scopes and git

Git access is decided by ownership, not by scopes: a personal key works on your personal circuits, an organisation key works on that organisation’s circuits. Scopes still apply to the REST API and the CLI, so pick them as if you were calling the API.

Clone and push

# Public circuit — no credentials needed
git clone https://qubithub.co/your-username/bell-state.git
cd bell-state

# Make a change
git add .
git commit -m "tune the ansatz"

# Push — git prompts for credentials
git push
# Username for 'https://qubithub.co': anything
# Password for 'https://[email protected]': qh_your_api_key_here

Reads ignore your credentials

Cloning or fetching a public circuit succeeds anonymously, so git never asks for a password — and if you supply a wrong one it is not used and not rejected. A read working therefore tells you nothing about whether your key is valid. The first thing that actually checks it is git push.

Skip the prompt

Store the key in git’s credential helper once:

git config --global credential.helper osxkeychain   # macOS
git config --global credential.helper libsecret     # Linux
git config --global credential.helper manager       # Windows

The next successful push saves the key; later pushes stop asking.

Embedding the key in the URL

https://x-access-token:[email protected]/... works, and is how CI usually does it. Be aware it lands in .git/config and in your shell history in plaintext. Prefer a credential helper for an interactive machine, and a secret store for CI.

What each failure means

What git prints	Status	Meaning
fatal: Authentication failed for '...'	401	The password was not a valid key or token — most often a truncated paste, or an expired or revoked key.
fatal: unable to access '...': The requested URL returned error: 403	403	The credential is valid, but that account cannot write to this circuit.
fatal: repository '...' not found	404	The circuit does not exist — or the key is the wrong tier for it: a personal key against an organisation circuit, or an organisation key against a personal one. Both look identical on purpose.

If git keeps re-prompting, your credential helper is replaying a stale key. Delete the saved entry for qubithub.co (Keychain Access on macOS, Credential Manager on Windows, secret-tool on Linux) and paste a fresh one.

CI and automation

git clone https://x-access-token:${QUBITHUB_API_KEY}@qubithub.co/you/circuit.git

Set QUBITHUB_API_KEY from your CI provider’s secret store. Give the key an expiry — the creation form accepts up to 365 days — and revoke it from the dashboard when the pipeline retires.

Related

• Authentication — JWT and API keys for the REST API
• CLI / SDK Quickstart — qubithub login, qubithub clone