aisync
Security model
What aisync protects, and what it doesn't.
What it protects
| Situation | Outcome |
|---|---|
| Your GitHub repo leaks | Tokens are ciphertext only and can't be opened without the passphrase |
A config file (.claude.json) is backed up or shared |
It holds references, so no token goes with it |
| Another website targets the admin UI | 127.0.0.1 only, a fresh token per run, Host and Origin checks |
| You paste a token into a file by mistake | The upload stops at the check |
What it doesn't
- An attacker who already controls this machine. The decryption key is in the keychain (a file on Linux), and while an MCP server runs its token is in that process's memory.
- A short passphrase. Someone with your repo can try passphrases offline. 600,000 PBKDF2 rounds slow this down; they don't stop it.
- Environment from
aisync run. A profile'senvgoes into the whole Claude process, so every command Claude runs can read it. MCP server tokens are different: they reach only that server. - Tokens the check misses. Token detection is rule-based and can miss formats it hasn't seen.
- Copies made before aisync. Old plain text in Claude Code's own backups (
~/.claude/backups/) is not removed by aisync.
GitHub access
aisync gets a token from gh auth token each time and never stores it. gh tokens usually reach all your repos, so keep your gh login safe.
Unattended machines
If macOS shows a keychain permission dialog, aisync waits up to 20 seconds, then stops and says why. On a machine nobody sits at, run aisync keystore file to keep keys in a file. Any program running as your user can read that file and it ends up in backups, so it is one step weaker than the keychain.
These docs describe aisync 0.1.