   .:.
  OPTA CODE
   ':'

reference Guide

Accounts Masterclass

A complete overview of the Opta Accounts infrastructure. Learn how local machines synchronize securely with cloud identities and centralize tool configurations.

Updated 2026-03-04

Ecosystem Role

While Opta is fundamentally "local-first", development teams need portability. Opta Accounts (hosted at accounts.optalocal.com) acts as the secure, encrypted bridge between your cloud identity and your local Opta CLI daemon. It handles Supabase SSO, license verification, and telemetry aggregation.

Local CLI

~/.opta/accounts.json

TLS 1.3 Handshake

Opta Cloud

Cloud Keychain & Token Rotation

Manually managing .env files across five different laptops is a security risk. Opta Accounts includes a Cloud Keychain. By running opta login, your CLI fetches an encrypted payload of your Anthropic, OpenAI, or Universal Provider keys and securely injects them directly into the daemon's memory. These keys are never written to plaintext files on disk.

$ opta login

> Opening browser to accounts.optalocal.com...
> Authenticated as [email protected]
> Synced 3 provider keys to in-memory keychain.
> Ready.

Security Boundaries & Blast Radius Control

Accounts is intentionally split into trust zones so a failure in one layer does not automatically leak the rest of your stack. The identity plane mints short-lived Supabase sessions, the secret plane holds envelope-encrypted provider credentials, and the policy plane decides what each local daemon can request. A signed local session may decrypt keys for runtime use, but it still cannot export raw secret payloads or bypass org policy checks. High-risk operations such as profile schema edits, license overrides, and org-wide policy pushes require scoped service roles and produce immutable audit event IDs. This design keeps login and sync workflows fast for developers while limiting blast radius during suspicious activity.

opta accounts policy inspect --effective

Session Scope: [profile:read, keychain:decrypt]
Blocked Cloud Ops: [key_export, license_override, telemetry_delete]
Audit Stream: append-only (retention: 365d)

Incident Recovery & Break-Glass Workflow

When a workstation is lost, malware is suspected, or token anomalies are detected, recovery should be deterministic rather than ad hoc. The recommended order is: open an incident, revoke all active refresh tokens, quarantine the affected device identity, rotate provider keys, and then re-authenticate from a clean machine. Accounts propagates revocation through websocket fan-out and heartbeat checks so stale sessions are cut quickly, while preserving read-only audit visibility for investigation. Because license manifests are signed, air-gapped commands remain available, but privileged account mutations are denied until trust is restored. Teams should run this playbook in a quarterly drill so responders can execute the sequence quickly under pressure and verify every control works as intended.

opta accounts incident start --device "mbp-14-matt" --reason "token anomaly"
opta accounts revoke --all-sessions --user [email protected]
opta accounts keychain rotate --providers openai,anthropic --invalidate-old
opta login --force --device-trust-check

Team Rollout Patterns For New Orgs

Large teams should not enable full autonomy on day one. A reliable rollout pattern starts with Ring 0 platform owners, then expands to a pilot group, and only then to all engineers once audit quality and recovery metrics are stable. During Ring 1, enforce strict defaults: read-heavy automation enabled, destructive write actions gated, and policy changes requiring two maintainers. During Ring 2, gradually relax controls per team based on measured incident rate and command approval latency. Accounts supports this by syncing profile bundles per org unit, mapping SSO groups to policy tiers, and providing drift alerts when local settings diverge from baseline. This staged model reduces onboarding friction while keeping governance consistent across devices and regions.

Rollout Rings

Ring 0

Platform owners validate SSO mapping, keychain import, and baseline policy.

Ring 1

Pilot teams run with guarded writes and two-maintainer policy approvals.

Ring 2

Org-wide rollout after drift, incident, and recovery SLOs remain healthy.

opta accounts rollout init --org "opta-core" --baseline "guarded-default"
opta accounts rollout promote --from ring-0 --to ring-1 --require-approvals 2
opta accounts rollout status --show-drift --show-sso-groups

Autonomy Preset Syncing

Your "Do Mode" preferences (e.g., auto-approving terminal commands but requiring approval for file writes) are deeply personal. Opta Accounts serializes your agent-profiles.json and syncs it. If you switch between your workstation and your laptop, your agent keeps the same trust boundaries seamlessly.

// Synced Profile Payload

"autonomyProfile": {

"autoApproveReads": true,

"autoApproveWrites": false,

"maxAutonomousDurationMs": 3600000,

"blockedTools": ["delete_file", "git_push"]

}

State: Synchronized across 2 devices

Local License Aggregation

Opta is distributed under a hybrid local license model. The Accounts daemon acts as the centralized verifier for all enterprise and pro-tier extensions (like the CLI Atpo supervisor). Instead of pinging the cloud on every command, Opta Accounts caches a cryptographically signed license manifest locally, allowing your apps to run in fully air-gapped environments while remaining compliant.

opta accounts status

License: Opta Pro (Active)
Air-Gap Validity: 14 days remaining
Features Unlocked: [LMX, Desktop, CEO Mode, Atpo]