Safety and Security

Safety and Security

threadnote is local-first and conservative by default: machine writes stay under THREADNOTE_HOME, only curated paths are imported, and nothing leaves your machine until you explicitly publish a memory. This page describes the safety model, what threadnote refuses to ingest, the built-in controls, the publish scrubber, and the review gates required before team-wide use.

Safety model: local by default, explicit when not

The default workflow assumes OpenViking is durable local memory, so every step that could capture sensitive material is scoped, redacted, or gated behind an explicit flag.

• Writes stay local. All memories and config live under THREADNOTE_HOME (default ~/.openviking). Nothing is uploaded or synced anywhere until you run share publish. Config files written under THREADNOTE_HOME use user-only permissions.
• Manifest-only seeding. Seed commands import only the paths declared in a seed manifest (config/seed-manifest.example.yaml or an explicit per-developer manifest at ~/.openviking/seed-manifest.yaml). threadnote does not index whole repositories — it is scoped to curated docs, memories, skills, and handoffs, not source navigation.
• Ignore rules. .threadnoteignore excludes build output, binary artifacts, local auth files, env files, and logs from import.
• Redaction on known config files. Recognized config files (.mcp.json, config.toml, and settings JSON) are copied through a redactor before import.
• Secret-pattern skip. Candidate files are skipped entirely if common token or private-key patterns remain after redaction.
• Managed instruction blocks. install upserts marker-delimited managed threadnote guidance into user instruction files (~/.codex/AGENTS.md, ~/.claude/CLAUDE.md, ~/.cursor/rules/threadnote.md, ~/.copilot/instructions/threadnote.instructions.md). Personal instructions outside the managed region are preserved; only the managed block is rewritten.
• Explicit agent config changes. mcp-install prints the commands and snippets by default. It only changes Codex, Claude, Cursor, or Copilot config when you pass --apply.
• Transactional, scrubbed sharing. share publish runs a secret scrubber, then writes, commits, and pushes the shared copy before removing the personal source. A git failure rolls back the shared write and leaves the original memory in place, so you never end up half-published.

Do not ingest

Keep the following out of memory entirely. The built-in controls reduce the risk, but they are best-effort and do not replace your judgment.

• Credentials, access tokens, API keys, certificates, private keys, or shell history.
• Customer data, production data, HIPAA data, or production logs — without explicit approval and scrubbing.
• Local auth files such as ~/.codex/auth.json, ~/.claude/.credentials.json, Cursor account/session files, or VS Code Copilot account/session files.
• Local settings files that may carry secrets, unless they pass through redaction.

Built-in controls

• .threadnoteignore excludes common secret and build-output paths.
• .mcp.json, config.toml, and settings JSON are redacted before import.
• Files are skipped if common secret patterns remain after redaction.
• mcp-install requires --apply before it changes Codex, Claude, Cursor, or Copilot config.
• install updates user-level Codex, Claude, Cursor, and Copilot instruction files through managed threadnote content. Existing personal instructions outside managed blocks are preserved.
• uninstall preserves local memories by default. --erase-memories is required before deleting THREADNOTE_HOME.
• Config files created under THREADNOTE_HOME are written with user-only permissions.

The publish scrubber

Only durable/ memories are shareable. When you publish one, share publish runs a best-effort scrubber over the text. Use --preview first to inspect the exact bytes that would land in git.

There are two classes of match:

• Hard-block credential patterns — publishing is refused regardless of --redact. Edit the memory to remove the value, then publish. Patterns include PEM private-key headers, OpenAI/Anthropic-style sk-... keys, GitHub classic tokens (gh[pousr]_...), GitHub fine-grained PATs (github_pat_...), GitLab PATs (glpat-...), HTTP Bearer ... tokens, bare JWTs (eyJ...), AWS access keys (AKIA...), and Slack tokens (xox[abcdeprs]-...).
• Redactable soft-leak patterns — local home paths. By default these also block, but --redact replaces each match with a placeholder and continues: /Users/<you>/... and /home/<you>/... become <local-path>.

The scrubber complements but does not replace human review. Strip the value, --preview, then publish. See Sharing Memories for the complete pattern list, false-positive notes, and the full publish/sync/unpublish workflow.

Rollout requirements before team-wide use

Start with a local-only pilot before any shared or team-wide rollout. Before broadening, get explicit legal and security review for:

Area	What to review
OpenViking licensing and operational use	Approve the dependency and how it is operated locally.
Embedding and summary providers	Use only company-approved embedding and summary model providers. For a solo pilot the default local embedding backend is fine; configure an approved provider in ~/.openviking/ov.conf before broader rollout.
At-rest encryption	Confirm at-rest encryption settings meet policy.
Local API key requirements	Confirm any local API key requirements are satisfied.
Forget/removal expectations	Define expectations for forgetting or removing stale or sensitive context.

A safe pilot sequence: doctor --dry-run, install --dry-run then install, start and confirm doctor reports a healthy server, seed --dry-run then seed, seed-skills --dry-run then seed-skills, and validate recall through one agent's MCP before adding a second. Seeding curated guidance should never import known secret patterns; verify that in the dry-run output.

See also: Sharing Memories, Configuration, Migration.