Data, recording and privacy
Local-first is not network-free. Exactly what is stored, what can leave, and the two switches that stop it.
What lives where#
The selected host owns your project files, Git worktrees, session history, local usage data, and most state under `~/.mirasim`; workspace-scoped configuration lives under `<workspace>/.mirasim`. Mirasim is local-first in the sense that your work is anchored to your host — and it is not network-free, because it talks to the model providers and channels you connect.
- Your code goes to the model providers you configured, under your own accounts — and to any IM channels you enabled, which necessarily pass through their platforms.
- Local models keep everything on the machine.
- Provider and connector secrets use the OS keychain where one is available, with a sealed fallback where it is not. Some subscription-account and relay state stays in local Mirasim configuration, so protect your user account and ~/.mirasim.
Raw recording, on by default#
On supported native passthrough routes, Mirasim records raw model requests and responses to `~/.mirasim/recordings`. This is the material the usage ledger is decoded from, and it is enabled by default — so it is worth knowing precisely, rather than discovering later.
- What is stored
- HTTP-layer facts plus the raw request and response bodies. With the default header redaction on, request headers are reduced to a safe whitelist; turning that off may retain credential-bearing headers.
- What it never does
- Block, mutate or break a live session. The recorder is off the hot path — if its bounded queue fills, it drops data and counts the drops rather than slowing the agent.
- Coverage limits
- Codex native capture requires OpenSSL. Profile-injected Claude and Codex turns currently stand down from capture, and some compatibility paths translate provider wires. Built-in and direct native-wire routes can still be captured.
# for one launch
MIRASIM_RECORD=0 mirasim
# persistently, from the next launch
touch ~/.mirasim/capture.off
# …then relaunch. Remove the file to enable recording again.Retention and the sweep#
A recording-enabled host sweeps on startup and every 30 minutes thereafter. Raw upload is conditional on an authenticated export destination being configured at all.
| Data | Removed after |
|---|---|
| Uploaded, complete recordings | 24 hours of inactivity |
| Recordings that were never uploaded | 30 days |
| Derived usage ledger entries | 90 days |
Direct CLI-only use does not run that sweep; cleanup resumes the next time a recording-enabled host runs. The traffic monitor tells you the ledger's footprint and the current export disclosure, and can reveal both the ledger and the recordings in Finder — so "what is actually on my disk" is something you can look at rather than infer.
Remote hosts and pairings#
- A keyed Android pairing uses application-layer end-to-end encryption when the pairing code carries the host's E2E public key. Legacy or keyless pairings do not — re-pair them.
- Manual remote desktop entries authenticate with a bearer token and carry no pairing E2E key. Use HTTPS/WSS, or a network you trust.
- A connection code contains the access token. Treat it like a credential.
- Selecting a remote host does not migrate the local host's pairings, IM configuration or schedules.
Something wrong or missing on this page? Tell us