Tsm

Tiny Secrets Manager

`tsm` is a tiny secrets manager for coding agents on macOS.

Coding agents need credentials for networked CLI tools and API calls. Yet storing credentials unencrypted in `.env` and JSON files is insecure. Even inside the macOS keychain, secrets may be readable by any process running as you.

Encryption at rest is not enough

The real question for a local secret is whether each *access* to it is deliberate.

`tsm` changes the unit of trust from "you are logged in" to "you unlocked this vault on purpose." The master key is gated by Touch ID, and every unlock is deliberate. Unlocks are also scoped to a single session: unlocking the vault in your working shell does not unlock it anywhere else, so a process in another terminal session has to clear its own Touch ID prompt, which you would see and could deny. Secret theft becomes noisy and time-bounded, instead of invisible and permanent.

What `tsm` defends against

• Cross-session access. A LaunchAgent, browser-spawned helper, prompt-injected agent in another terminal, or any other process running as you that connects to the daemon socket while your main session is unlocked still has to clear its own Touch ID prompt — which appears on your screen and which you can deny. Sessions unlock independently; unlocking your working shell does not unlock anyone else.
• Absent user. The vault auto-locks on screen lock and system sleep, so an unattended laptop is not an open vault.
• Secrets at rest. The vault file is AES-GCM encrypted. The master key lives only in the macOS Keychain (Touch ID gated) and in daemon RAM while at least one session is unlocked — never on disk in the clear.

What `tsm` doesn't defend against

`tsm` is not a sandbox. A process that has compromised your unlocked session — for example, a prompt-injected coding agent in the same shell where you ran `tsm unlock` — can read any secret you have not gated with `[confirm]`, just as you could. Confirm-gated secrets st