Skip to main content

Credentials & Local Data

Local by default​

By default, session transcripts, chat organization, Notebook and Notes, run records, checkpoints, schedules, workspace indexes, usage summaries, Browser Autofill data, and encrypted continuity live on the Mac. Opted-in remote work stores its selected project snapshot and runtime records on the destination host. Local Ollama prompts and screenshots stay on the configured Ollama route.

Hosted providers receive only requests you send through their route. Automatic hosted team routing requires separate consent. Optional ChatGPT web search sends search queries to OpenAI only when its per-account toggle is on.

Credentials​

API keys, managed account state, MCP tokens, mobile keys, memory keys, and Browser Autofill records are kept in macOS Keychain or scoped user-readable credential stores designed for their owning helper. They are never returned through ordinary model-visible APIs. Authenticated non-loopback provider endpoints require HTTPS and cannot redirect credentials.

ChatGPT-plan OAuth stays inside the isolated Codex helper. Claude plan preview uses its own managed helper and per-account credential home, separate from API accounts and existing Claude installations. Team workers use an authenticated broker rather than owning subscription credentials.

Browser Autofill stores passwords, contacts, and payment cards in Keychain. Agent access is opt-in by category; password access is limited to the current origin. Page scripts cannot enumerate the vault.

What is persisted​

  • Transcripts are append-only local JSONL with separate organizer metadata.
  • Saved-chat search caches use encrypted session envelopes and an in-memory full-text index. This does not encrypt the raw transcript JSONL files or remove historical backup copies.
  • Run history is a local SQLite store with credentials, hidden reasoning, provider signatures, and secure-field values removed. Task records also retain immutable plans, tool receipts, verification evidence, invocation usage, and bounded captured file history for restoration.
  • Approved memory and continuity snapshots are encrypted with AES-256-GCM; the backend key is a local memory/master.key file with user-only access. Identity Vault uses its own edition-specific Keychain key.
  • Notes save locally under a one-way hash of their resolved chat, workspace, or shared owner; the Notebook adds searchable owner labels and preserves unmatched older notes under Unlinked.
  • Attachment names can appear in transcripts, but image/file bytes are not persisted in normal chat history.
  • Exporting with attachments deliberately copies those bytes into the exported artifact.
  • Browser data is ephemeral by default; an optional per-workspace persistent profile stores its own cookies, local storage, and browsing history.
  • Mobile pairs a pinned certificate and scoped device record; no cloud relay stores the conversation.

Companion presentation data​

Your companion stores its name through the existing saved-agent profile, with separate local appearance and animation preferences. Custom portraits use the existing image store. Imported pixels are validated and re-encoded; appearance references do not store private generation prompts or temporary provider URLs.

Character setup does not grant permissions or enable memory ingestion, remote access, computer control, microphone access, notifications, or automatic monitoring. Generating custom art is a separate explicit action that sends the description to the displayed image account and may incur charges.

Memory and restore protection​

Memory inspection and review expose the final revalidated submission and its delivery state. Memory travels as scoped reference data. Native Codex memory is a per-agent opt-in; helper suggestions remain candidates until reviewed. Disabling memory or forgetting an item cannot retract context already delivered to a provider.

On macOS, the signed memory helper keeps an authenticated deletion checkpoint in the login Keychain. Memory settings show protection, unavailable custody, or recovery-required status. An enrolled profile blocks memory operations when checkpoint protection cannot be verified rather than treating missing counts as an empty vault.

Checkpoints detect missing deletion history but do not contain the lost deletion entries. Recovery may expose information forgotten after a restored backup. Restore the newer ledger where possible; offline recovery requires authenticated evidence and explicit acknowledgment of lost history. A locked Keychain must be unlocked; unknown or corrupt checkpoint generations cannot be reset to zero to bypass recovery. Hosts without supported custody report protection as unavailable.

Keep profile backups private. Memory exports remain readable by design, and neither forgetting an item nor restoring a checkpoint can erase historical copies already exported or sent to providers.

Editions and Identity Vault​

Standard Locus excludes cryptocurrency wallets, wallet tools, and browser wallet-provider injection. LocusX is a separate edition with an independent app profile. Existing wallet files and Keychain entries are left untouched, with no automatic import or migration.

Identity Vault encrypts reusable private details and documents separately. Exporting a version creates a decrypted file at a destination you choose. Approved releases and generated model replies have their own retention; revocation cannot recall already shared data.

Deleting a chat moves it to recoverable local storage and does not delete workspace files.

Library and saved outputs​

Document knowledge is opt-in per workspace. Import copies external documents into the workspace's visible Locus Documents folder. Chat attachments do not automatically enable persistent knowledge.

Outputs stores metadata and immutable file snapshots locally under Application Support. These are ordinary local deliverable snapshots, separate from the encrypted Identity Vault. Removing output history does not delete original files; reaching a storage budget does not silently purge saved history.

Independent and remote runtime data​

Enabling the independent runtime allows the supervisor to retain only API and connector credentials explicitly provisioned for it. Its separate private store uses user-only access and stays outside project snapshots, event records, deployment logs, and result exports. This is an additional storage boundary beyond the desktop's ordinary in-memory credential handoff.

SSH deployments carry selected credentials through the authenticated tunnel, not command arguments. Subscription accounts sign in independently and use separate credential homes on the destination. Project snapshots are reviewed before transfer and show exclusions for secrets, caches, ignored files, and unsafe paths.

The trusted local helper and selected remote machine can access provisioned work. The host owner, or a process with the same account access, can read credentials stored there. Host-key verification, a private controller token, and loopback-only APIs protect against untrusted network clients; they cannot make a compromised host trustworthy.

Removing a connection preserves remote files, work, and credentials. Stop and retire the service and revoke provider access separately when decommissioning a host. Returned results are reviewed before local application. Runtime updates retain previous packages and database backups for recovery.

Task restoration stores bounded before/after content for eligible task-owned edits. It is ordinary local or runtime task history, not encrypted Identity Vault storage. It does not undo external actions or delete conversation history. Private Identity tasks are excluded from task journals and restoration history. See SSH & Remote Runtimes and Task Recovery & Restoration.