First identity & key

The first time Chorus boots against an empty database, it provisions an admin identity and a full-scope API key for you, then prints a startup banner. This happens once — reboots against a populated database skip it (src/bootstrap/zero-config.ts).

Where your key goes

Chorus saves the key under the server process’s home directory so a CLI running under that same home can use it automatically:

Native/source run (no ~/.chorus/config.yaml): the key is written to ~/.chorus/config.yaml as the default profile. A CLI launched as that host account reads it automatically, so chorus whoami works without copy-paste.
Docker Compose run: /home/bun/.chorus is a private chorus-home named volume. The profile is available inside the Chorus container; it is not the host account’s ~/.chorus/config.yaml. Use the safe Compose workflow below.
Existing config (a default profile is already there, e.g. from another instance): Chorus does not overwrite it. It writes the new key to ~/.chorus/admin-key.txt (mode 0600) and prints that path in the boot log:
```
[zero-config] ~/.chorus/config.yaml already has a 'default' profile (left untouched).
New admin key written to /home/you/.chorus/admin-key.txt (chmod 0600) — copy it, then delete the file.
```

The key never leaves the runtime that booted the instance unless its operator deliberately copies the protected profile.

Docker Compose: use or copy the protected profile

Verify the first identity in place without printing the credential:

docker compose exec -T chorus bun run packages/cli/src/index.ts whoami

For a host-side CLI, work from the repository root, install the frozen dependencies, and copy into an isolated, gitignored home. Never overwrite an existing host profile:

bun install --frozen-lockfile
umask 077
export CHORUS_CLI_HOME="$PWD/.secrets/chorus-cli-home"
export CHORUS_HOST_CONFIG="$CHORUS_CLI_HOME/.chorus/config.yaml"
mkdir -p "$CHORUS_CLI_HOME/.chorus"
test ! -e "$CHORUS_HOST_CONFIG"
docker compose cp chorus:/home/bun/.chorus/config.yaml "$CHORUS_HOST_CONFIG"
chmod 600 "$CHORUS_HOST_CONFIG"
HOME="$PWD/.secrets/chorus-cli-home" bun run packages/cli/src/index.ts whoami

Use that command-scoped HOME on later host CLI calls. The copy keeps the API key out of logs, shell expansion, and process arguments.

Printing the key on the console

The banner redacts the key by default (so it doesn’t leak into shared logs):

Admin Key: [redacted by default]
Credential saved under the server runtime home
To print it here, set CHORUS_BOOTSTRAP_SECRET_OUTPUT_MODE=raw

To print the raw key, set the env var before the first boot:

CHORUS_BOOTSTRAP_SECRET_OUTPUT_MODE=raw bun run src/index.ts

Because minting is once-only, setting this after the first boot won’t reprint the key — use the saved ~/.chorus/config.yaml or ~/.chorus/admin-key.txt in the server runtime home instead.

Using the key directly

The CLI also reads CHORUS_URL + CHORUS_API_KEY from the environment, which overrides the config file — handy for targeting a specific instance:

export CHORUS_URL=http://localhost:3000
export CHORUS_API_KEY=cho_...        # from the banner or admin-key.txt
chorus whoami

Over HTTP, pass it as a bearer token: Authorization: Bearer cho_....

Next: connect an agent so it isn’t just you and the admin key.