Seorak watches your coding sessions without reading your code. It derives a small set of stats on your machine and ships only those, never the work itself. That sounds like a privacy disclaimer. It is actually the design. The line between what stays and what leaves is not a setting you toggle on. It is the shape of the product, drawn before anything is sent anywhere. Where the work happens Most tools that watch your activity solve the problem by collecting everything and sorting it out later on a server. The code, the prompts, the file contents, all of it shipped, then filtered behind someone else's privacy policy. We did not want that boundary to live on a server we control. We wanted it to live on your machine, where you can reason about it. So the capture happens locally. The collector reads what a coding agent emits, Claude Code and Codex today, derives the stats there, and sends only the result. A session reached a commit, or it did not. It ran a while. It cost a certain amount, derived from the token count. The lines it changed were still on the branch a few days later, or they were not. Those are small facts. They travel. The thing they were derived from stays put. Seorak ships the count, never the thing that was counted. This boundary has names outside this product. Keeping what you collect limited to what a purpose actually needs, rather than everything that might be useful, is the principle privacy law calls data minimisation, and its test is necessity, not usefulness. Drawing the line before anything leaves the machine, instead of collecting first and filtering on a server afterward, is the older idea of privacy by design: privacy as the default, set up front rather than patched in later. We did not build the boundary to satisfy either one. They are just what it looks like described from the outside. Identifiers follow the same rule. A repo or a file is not sent by name. It is a salted hash, computed locally, stable enough to group sessions over time but not reversible into a path or a filename. So the longer read across your sessions works without anyone, including us, holding a map back to your actual files. What stays, what leaves The full list of stats is short by design: session state (active, idle, stuck, needs-you), duration, token count and the cost derived from it, stalls and retry loops, whether a run reached a commit, line survival, and a few replay keyframes worth reviewing. That is everything. Here is the split, plainly. Stays on your machine, Leaves as a stat Source code and diffs, A duration, e.g. 40 minutes Prompts and agent replies, A state: active, idle, stuck, needs-you File contents and file paths, A token count and the cost derived from it Repo and file names, Salted hashes standing in for them The text of an error, "First error" as a replay keyframe The values above are examples of shape, not measurements. Your numbers are your own. The honest limit: because we never read content, Seorak cannot tell you why a session stalled or what the stuck retry loop was about. It can tell you that a run stopped moving, that lines churned instead of surviving, that cost spiked at a particular moment. The reading of why is still yours to do. We think that is the right division of labor. The stats point you at the few moments that deserve a look. The look is human. Why the boundary is worth keeping This is also why the collector can be opened later. When the boundary between your machine and the derived record is clean, the part that runs on your machine has nothing to hide and can be read in the open. That is a consequence of the boundary, not the reason for it. The reason is simpler. The code you write with an agent is yours, and the easiest way to keep it that way is to never send it. A session is a small thing seen from the outside. It started, it moved or it stalled, it cost something, it left lines that lasted or lines that did not. You can learn a fair amount from that without anyone reading a single line of what you wrote.