Skip to main content
The CLI is a trusted local or server-side client. Interactive use defaults to a revocable OAuth grant. CI and other headless environments can use a dedicated API key.

Use least-privilege keys

Create a separate key for each human machine or automation boundary. Grant only the scopes its commands need. Read-only agents should not receive write scopes, and a changelog job does not need integration or billing access. The API derives the workspace from the verified key. Repository config and CLI arguments cannot replace that identity, and requests for another workspace’s resources return not_found without revealing whether the resource exists.

Keep credentials out of arguments

Use browser OAuth for a human:
Use a secret-managed environment variable or stdin for automation:
--api-key is a boolean switch that opens a masked prompt; it does not accept a key value. The CLI never accepts a key positionally. Do not put a credential in .gleanfeed.json, a source file, shell history, process title, CI argument list, debug log, or agent prompt.

Separate repository and credential state

.gleanfeed.json contains only non-secret workspace selection. Credentials live in the current user’s application config directory with owner-only permissions on macOS and Linux and user application-data ACLs on Windows. See Profiles and repository config for the exact schema. --debug writes only limited command, profile, workspace, and endpoint context to stderr. Error handling strips raw errors, stacks, request bodies, authorization headers, keys, tokens, client secrets, and passwords.

Keep metadata non-secret

Feedback capture accepts small source metadata for private triage context. The CLI rejects credential-shaped keys and values, but callers still must avoid passwords, tokens, cookies, raw connector payloads, private message history, and unnecessary personal data. --agent is only a 1–64 character audit label. Never put a token, email, command, or customer content in it.

Understand analytics

Authenticated REST requests emit low-cardinality operational events containing workspace ID, route template, method, status, error state, transport, credential kind, and the fixed cli client kind. They do not contain request or response bodies, concrete resource IDs in route paths, commands, credentials, repository data, URLs, or personal data. On the production API, successful auth login and init handshakes also emit fixed activation events. The init event is best-effort and can be disabled with GLEAN_FEED_TELEMETRY=0. Disabling it does not disable required authentication, rate limiting, or operational API metering.

Rotate and revoke

Browser OAuth access tokens refresh automatically with rotation. auth logout attempts to revoke the grant remotely and always deletes the local tokens. For an API-key profile:
  1. Create a replacement key with the same or narrower scopes.
  2. Run gleanfeed auth login --profile NAME --api-key and validate auth status.
  3. Update the CI secret when applicable.
  4. Revoke the old key in Settings → API Keys.
Logout removes the local API-key copy:
If a key may have appeared in version control, logs, chat, an issue, or an artifact, revoke it immediately. Deleting or redacting the visible text does not invalidate a credential that was already copied.