Primacode
Install and sign in
How the desktop build will get a key and a repository of its own. Decided, not built.
Planned Decided and written down. Not built, or built and not yet released. Do not integrate against it until the card says live.
What it does
Nothing yet. This card describes a decision, so that nobody builds against a guess: sign-in is the whole of the remaining desktop work, and it is designed and written down.
The shape: "Sign in with Prima" opens the system browser at the developer portal, the portal hands back a code on a prima:// callback, the code is exchanged for a token, and the account service mints a per-device key carrying the ai scope. The key goes into the operating system's keychain.
Signing out revokes that device key. One device, one key, revocable on its own.
Until that ships, the binary takes a key from the environment or from a file you create. That path works today and is what the configuration rows below describe.
Inputs and outputs
| Today, the key | PRIMA_API_KEY, or a mode-600 file whose path the binary prints when the key is missing. There is deliberately no command-line flag: a flag lands in shell history and in the process table, where it outlives the session. |
|---|---|
| Today, the gateway | https://api.prima.li/api/prima/v1 on a development build. A release build has no default and refuses to guess. |
| Planned, sign-in | System browser to the developer portal, prima://auth/callback?code=… back, token exchange, per-device key. |
| Planned, key storage | The operating system keychain, as the highest-precedence source in the existing resolver. |
| Download page |
Configuration
PRIMA_API_KEY | The key itself. First place the resolver looks. |
|---|---|
PRIMA_API_KEY_FILE | A file holding the key, mode 600. Second place the resolver looks. |
PRIMA_BASE_URL | The gateway. One environment variable, deliberate and per run, and visible in the command that set it. |
PRIMACODE_CHANNEL | release refuses to fall back to any default gateway. Development builds fall back to the public one. |
Limits
- There is no download link yet, and there will not be one until a signed, notarised build exists. Code-signing paperwork with both platform vendors is the long pole and is tracked separately.
- Installers have been produced by hand on one machine, unsigned. A continuous-integration job that builds one is written and has never run; it uploads a build artifact and deliberately does not publish a release, because the first public download link is a decision a person takes.
- The desktop tests exist and are meant to run in continuous integration. That gate has never run.
- Everything under "planned" above is a decision, not a description of running software. If you are integrating against it, wait for the card to say live.
Example
pointing a development build at the gateway today
export PRIMA_API_KEY=prima_pk_…
export PRIMA_BASE_URL=https://api.prima.li/api/prima/v1Source of truth
philosophers_stone/operations/prima-onboarding-implementation-plan.md § W9 (the sign-in shape, the per-device ai-scoped key, the keychain, sign-out revocation)philosophers_stone/operations/prima-onboarding-implementation-plan.md § W10 (no download link until a signed, notarised build exists)primacode/packages/primacode/src/config.ts (key resolution order, no CLI flag, `DEFAULT_BASE_URL`, the release-channel refusal)measured 2026-09-11 against primacode `origin/claim-event-model`: commit 9671c4e8c adds a CI installer job, unsigned until the signing variables exist, artifact only, never yet run; commit d889c9745 brands the provider sign-in page and is not a "Sign in with Prima" flow