How Bring Your AI Handles Privacy and File Safety

Updated

Bring Your AI is built local-first: the CLI runs on your own machine, target config stays local, and your original files are never changed. Safety comes from three layers working together — read-only source files, snapshot-before-write with rollback, and review-gated plans you approve before anything moves. If you need to migrate agent context across Claude Code, Codex, and Cursor without handing your setup to a hosted service, this design is aimed at exactly that.

The privacy boundary: local-first by default

The product's stated position is that local-first is the product, not a setting you enable.

  • The CLI runs on your machine. Migration, sync, and distillation happen locally rather than on a remote service.
  • Target config stays local. Platform-native configuration is not centralized or uploaded.
  • No hosted account required for sync. Machines sync through a local hub you can place in your own Git repo, so the "central" copy is one you control.
  • No-data remote MCP. The remote MCP path is described as no-data, and safe MCP follow-up is included in the audit.
  • License verification is local. Checkout produces a signed local license proof, and validation does not phone home.

One boundary is worth reading carefully: the page describes remote discovery as the edge of the local-first model. Local-first covers the CLI, the hub, and target config — it does not mean every optional capability is offline, so check the specific path you plan to use.

File safety: read-only sources, snapshots, rollback

The write behavior is the part most people care about, because a bad migration can wreck a working setup.

Guarantee What it means in practice
Source files are read-only Your existing Claude Code or Codex setup is read, not modified
Target files are snapshotted before write A rollback point exists before any change lands
Rollback snapshots Restore the previous state if the result isn't right
Merge keeps existing Codex setup Migrating in doesn't wipe what's already configured
Original files unchanged Stated as a core property, not a best effort

The preview step is where you verify this before committing:

$ bringyour preview --from claude-code --to codex
Claude Code found.
Codex found.
Move supported: yes
Existing setup can be kept: yes
Original files will not be changed.

Then the migration itself reports what it did and where the rollback point lives:

$ bringyour migrate --from claude-code --to codex --policy merge
rollback snapshot: ~/.codex/.bringyour-snapshots/...
validation: BRINGYOUR-VALIDATE.md
✓ memories + rules
✓ MCP review notes
✓ skills + validation
✓ rollback snapshots
! hook differences flagged
✓ PII scrub audit

Two details matter here. First, --policy merge is what preserves an existing Codex setup; a different policy may behave differently, so confirm before running. Second, the ! on hook differences is a flag, not a failure — hooks often can't be translated cleanly between harnesses, and the tool surfaces that instead of silently dropping them.

Review-gated execution and the audit artifact

Nothing runs unreviewed. Plans are review-gated, meaning you inspect the migration plan before it executes, and the output includes an audit artifact covering:

  • hooks
  • MCP review notes
  • secrets
  • AGENTS.md / CLAUDE.md scope
  • validation notes

The MCP migration guide preserves command and environment references while flagging values that should stay in Keychain or environment variables rather than being written into config. The PII scrub audit in the migration output is the same idea applied to personal data.

Distillation: keeping the useful parts, stripping the risky ones

If your concern is sharing or archiving a setup, the distill path creates a sanitized Claude, Codex, or Cursor harness bundle with redaction metadata and verification. This is the right path when you want a portable snapshot rather than a live migration — the redaction metadata tells a reviewer what was removed, and verification confirms the bundle is intact.

What to check before you rely on it

  • Run preview first, every time. It tells you whether the move is supported and whether your existing setup can be kept.
  • Confirm your policy. merge preserves existing target setup; other policies may not.
  • Read the flagged items. Hook differences and MCP values that belong in Keychain or env are the two places where a migration can look clean but behave differently.
  • Keep the snapshot path. It's printed in the migration output — that's your rollback.
  • Check the specific path's boundary. Local-first covers the CLI, hub, and target config; remote discovery is described as the edge of that model.

Pricing and access terms aren't covered here — the site lists a Pricing page, a Buy page, and a Team Migration Pack at $499 for up to 10 people, with lifetime access offered while the product is young. Check those pages directly for current terms rather than assuming what's included.