Privacy & storage

Context OS uses a hybrid privacy model, applied in this order:

1. Secret scrubbing in your browser. Keys and tokens, passwords, webhook links, credentials in URLs and commands, private keys, seed phrases, card numbers and IBANs are replaced before upload, in titles as well as text. The real values stay in a local .env.example file on your device. Text you write yourself is checked on our servers: the editor warns before it saves a secret and stores a placeholder such as [REDACTED_SECRET_1] once you confirm, and secrets pasted into a Vault Chat question are removed before it reaches the AI. A file sent to the vault's sync API with a secret still in it is skipped instead of being stored.
2. Short-lived distillation in server memory. The AI needs readable, secret-free text, so the managed cloud is not zero-knowledge while a vault is being built or served to agents. Staged uploads are deleted when the build ends; sources a budget-limited build could not distill stay staged, encrypted, for up to 7 days so a purchase can finish the build without a second upload. Bringing your own storage or AI key does not change where distillation runs; only self-hosting keeps all plaintext off our servers.
3. Encryption at rest. Your content is stored encrypted with a per-vault AES-256-GCM key: file bodies (with their TL;DRs and tags), folder purposes and routing rules, file history, undo records, Quarantine diffs and reasons, uploads waiting to be distilled, and the intermediate results of a build. File and folder names, sizes and dates stay readable so the vault can be organized. Agents and builds keep working, because our servers hold the key: only the passphrase lock removes that.
4. Optional passphrase lock for zero-knowledge storage (below).

Passphrase lock

Your browser encrypts every file, and the folder purposes and routing rules, with a key derived from your passphrase (PBKDF2, 600,000 iterations); the server stores only that ciphertext and a keyed integrity check per file, never a plain hash of your content. Each encrypted file is bound to its vault and to its file, so stored files cannot be swapped unnoticed. File and folder names stay readable. While the vault is locked, MCP, the extension, voice notes and builds pause. Unlock it in the browser to resume, or download a decrypted ZIP. Unlocking decrypts in your browser and hands the files back to the server, where encryption at rest applies again.

The lock card checks the strength of your passphrase and offers a recovery kit, a text file made in your browser (it includes the passphrase only if you choose so). A wrong passphrase is shown right at the field. If the passphrase is right but a stored file is damaged or was altered, unlocking stops and names that file, so you can contact support before anything changes.

Only the vault's owner can lock it (for a team vault, the organization's owner), and only after signing in within the last 15 minutes, so a forgotten or stolen session cannot lock everyone out. The owner, and admins who can open every folder, can unlock it.

A lost passphrase cannot be recovered. Keep it in a password manager. Approve or reject pending Quarantine proposals before locking: a locked vault keeps nothing the server could read, so locking also deletes the file history, undo records, resolved Quarantine diffs, any staged sources waiting for more tokens, and unfinished lock or unlock steps, and takes a public SOUL.md profile offline.

File history and undo

Every change to a knowledge file keeps the previous version, encrypted like the file, for 30 days (up to 50 versions per file). The app does not show this history: to get an earlier version back, email support@contextos.dev with the vault, the file and the date you need. Moves, folder renames and Magnet runs can be undone for 7 days: undo restores only what that action changed, never changes folder permissions, and refuses when the files have changed since, so it cannot overwrite newer work.

Public SOUL.md profile

You can publish a vault's SOUL.md at a link from the vault's Settings. You review it first, and only the version you approve is public: when a later build or agent adds facts, the page keeps showing the approved version until you publish the update. Only SOUL.md is shown (without the instructions meant for AI agents), never your files; search engines are asked not to index it, and you can unpublish it at any time. A vault with nothing to say yet cannot be published.

Your own storage (BYOS)

Mirror a vault to your own GitHub repository or S3-compatible storage (AWS S3, Cloudflare R2, MinIO, SeaweedFS); any other HTTPS git remote (GitLab, Gitea…) is available on self-hosted nodes. Credentials are stored encrypted. Changes are mirrored every 15 minutes or when you click Sync now, and only changed files are written. .env.example never leaves your device. Only the vault owner can connect or sync external storage, because the mirror contains every folder, and the mirror pauses if your plan no longer includes your own storage. One target mirrors one vault: give each vault its own repository, branch or bucket, or its own path prefix; a target that already mirrors another vault is refused.

Local folder sync

In Chrome, Edge or Brave, link a folder on your computer once under Local sync. The vault then reads and writes that folder directly, like a desktop app. Edits are batched after a quiet period, and identical content is never written twice, so syncing cannot loop. Other browsers can download the vault as a ZIP instead; edits to that copy do not sync back, so make your changes in the app.

Sync runs while your vault is open in a browser tab. The first sync shows what will be written and uploaded and waits for your OK. API keys and passwords in your files stay on your computer: the vault stores placeholders. A note you copy on disk becomes a new vault file; the original stays where it is.

• Keep .context-os-key. Context OS writes this small file into the folder and never uploads it: it gives each secret the same placeholder in every file. If you delete it, your secrets simply get new placeholders on the next sync.
• The only copy of a secret is never deleted. A file the vault moves or renames moves on disk with its secrets. When the vault deletes a file whose secrets exist nowhere else in the folder, the file stays on disk and the sync tells you.
• Very large files are skipped. A file over 1,000,000 characters is neither uploaded nor overwritten; the sync lists it.
• Generated files belong to the vault. The routing maps, folder README.md indexes, Changelog.md, .cursorrules and .windsurfrules are written by Context OS and are read-only. If you edit one on disk, the vault's version replaces it and your text is kept next to it as a conflict copy (for example AGENTS (conflict 2026-11-14).md). A README.md, AGENTS.md or Changelog.md you write yourself is stored as README_Notes.md, AGENTS_Notes.md or Changelog_Notes.md, so it never replaces a generated file.
• Hidden folders are not synced. Folders whose names start with a dot, such as .git, .github or .vscode, stay out of the vault.
• Renames sync both ways, also when only the case changes (notes.md → Notes.md) on a Mac or Windows disk, where both spellings are one file.

Obsidian

A vault is plain Markdown with YAML frontmatter, so a synced folder or ZIP export opens directly as an Obsidian vault. Turn on Obsidian vault compatibility under Local sync to add sensible .obsidian/ defaults (graph colours per numbered folder, generated maps hidden). Existing Obsidian settings are never overwritten, and you can switch the generated maps to [[wiki-links]] without touching your own notes.

Vault limits

Each vault holds up to 10 MB of notes (the generated maps, folder indexes and the Changelog don't count) and 5,000 files. A save that would go past a limit is refused with a message, and a build that fills the vault stops with "Your vault is full": delete or shorten some notes, then distill again. Edits that keep or reduce the size always work, so a full vault can always be tidied up. A vault can also have up to 50 active API tokens and 50 active share links: revoke one you no longer use to make room.

Account security

Turn on Two-factor authentication under Settings → Security. It then asks for your code after every sign-in with your password, a magic link, an e-mail verification link, or Google or GitHub (a passkey is a second factor in itself). When you turn it on, you get backup codes, shown only once: copy or download them and keep them somewhere safe, such as a password manager. Each code works once: on the code step, click Use a backup code. New backup codes, in the same place, asks for your password and replaces your codes; the old ones stop working.

Passwords need at least 10 characters, and common ones (such as Password123! or 1234567890) are refused.

To delete your account, open Settings → General and click Delete account. You type your e-mail address to confirm, and enter your password; an account without a password needs a sign-in from the last 15 minutes (Sign in again). If you are the only owner of an organization that still has members, make another member an owner first (see Teams & organizations); what happens to your subscription is in Plans & billing.

Teams and enterprises

Organizations on the Team or Enterprise plan can review our processor terms, security measures and subprocessors (Google Gemini, Neon, Vercel, Inngest, Resend, Stripe and, for voice transcription, OpenAI) in the Data Processing Addendum. Bring-your-own-key keeps AI calls in your own provider account, and a self-hosted deployment keeps all processing on your infrastructure.