What encrypts
When the server can read the passphrase from the keystore, every JSONL line is encrypted with Fernet (AES-128-CBC + HMAC-SHA256) before append. The switch is whether that read succeeds, not merely whether the entry exists: a missing entry, a locked login keychain, a read that times out or a missing security binary all come back empty, is_enabled() is false, and the logger writes plain lines. The read is cached for the life of the process, so a keychain that was locked when the server started means plain lines until the next restart. That is why the read side never assumes ciphertext. The passphrase lives in the local OS keystore (security find-generic-password -s {service-name} -a {account-name}). SHA-256 of the passphrase derives the Fernet key deterministically — any Mac that knows the passphrase reads any encrypted JSONL. Machines without the keystore entry store the encrypted files opaquely as blob-backup endpoints.
가림막 — peace of mind
The threat model is honestly named: 가림막 (Korean for 'screen' or 'cover'). It defends against accidental visibility — Finder or Path Finder previews, shoulder-surfing, fleet sync going somewhere new — not against a determined attacker with filesystem + Keychain access. We're not pretending otherwise.
Plain + encrypted coexist
Read paths auto-detect by first byte: { is plain JSON, g is Fernet base64. A single JSONL may carry both during/after migration, and reads handle either.