CLIProxy Runtime Credentials

FractalOps uses CLIProxyAPI as a runtime credential gateway, not as an agent process adapter.

Boundary

Agent process adapter selection remains codex-cli, claude-cli, antigravity-cli, browser-only, or workspace-cli.
cliproxy exposes a short-lived proxy handoff for CLI adapters that need provider account material.
Armory attaches the codex-cli-runtime bundle when an agent uses the Codex provider, and the antigravity-cli-runtime bundle when an agent uses the Antigravity provider (antigravity, antigravity-cli, google-antigravity).
The credential broker returns only lease metadata, fingerprint, provider, proxy URL, model prefix, and OpenBao artifact ref.
Raw OAuth/account material never leaves OpenBao through Portal, Studio metadata, GitHub issues, or browser DOM.
Employee browser access is not a shared management-key login. A human principal that mints cliproxy without an explicit org-managed artifact is defaulted to the agent-squad:user-codex runtime provider profile: credential_scope=user_owned, binding_mode=auto_bind_user_oauth, and workspace_binding=daytona_workspace.
The connector catalog treats cliproxy as JIT, not UI-only: solution grants plan upsert_cliproxy_access and require identityEmail before access reconciliation can proceed.

Storage Contract

Canonical OpenBao scope:

fractalops/default/runtime-providers/cliproxy

Canonical state backend:

PGSTORE_DSN -> shared CNPG database `cliproxy`
PGSTORE_LOCAL_PATH -> /CLIProxyAPI/pgstore

CLIProxyAPI’s official Postgres store owns runtime configuration and OAuth/auth files. The pod-local path is only a mirror/cache. Do not reintroduce cliproxy-auths PVC for credential state; runtime updates go through /v0/management/* and persist to CNPG.

If legacy OAuth JSONs are found on a retained cliproxy-auths Longhorn PV, treat that PV as recovery evidence only. Rebind it read-only, import JSON records into CNPG public.auth_store, restart cliproxy so PGSTORE rebuilds its mirror, and verify GET /v0/management/auth-files before deleting or releasing the old volume.

Runtime provider secrets use Portal secret scope runtime_provider, which maps to:

runtime-providers/{provider}/{environment}/secrets

Example key:

CODEX_OAUTH_BUNDLE

The credential broker default artifact ref is:

ref:runtime-providers/cliproxy:CODEX_OAUTH_BUNDLE

Deployment

Optional manual container build context: ops/containers/cliproxy
Deployed image pin owner: platform/k8s/environments/*/runtime.cue
Manual image build workflow: .github/workflows/cliproxy-release.yml (does not write GitOps)
GitOps application: platform/k8s/argocd/runtime/resources/cliproxy.application.yaml
Kubernetes app: platform/k8s/apps/cliproxy
Runtime asset id: cliproxy-runtime
Internal service: http://cliproxy.fractalops.svc.cluster.local:8317
Public protected host: https://cliproxy.yamon.io

The Kubernetes deployment seeds one GitOps-owned config.yaml, then CLIProxyAPI persists runtime changes through its official Postgres store (PGSTORE_DSN). Account import and OAuth rotation are explicit high-trust operations; they are not inferred from ~/.codex, ~/.claude, or any host-local credential directory.

The usage exporter is part of the same GitOps app, but its image is not owned by the chart default. platform/k8s/environments/*/runtime.cue must project the current fractalops-api image into usageExporter.image because the exporter module is baked into that API image. A stale chart-default image is a deployment defect.

The public management console is Pomerium protected. Its sidecar may seed a non-secret browser placeholder so the CLIProxy management SPA skips its local #/login page, but that placeholder is not an employee credential. Per-employee model access is issued by PortalCredentialBrokerService through /v1/portal/credentials/cliproxy/mint and /exchange, then bound to the workspace runtime profile.

Policy

Low-risk scopes:

open, bootstrap

High-risk scopes requiring trusted device and WebAuthn:

account_import, raw_oauth_rotation, admin