Great question @Mordrag, three design decisions make this work:
1. Git runs first, Oobo enriches afterwards. Oobo sits in front of Git as a transparent proxy (aka git=oobo). When you run git commit or obo commit, the original git binary is executed first and completes at full native speed. Only after successful commit, Obo appends metadata like session links, attributes, token count. If something goes wrong in the enrichment phase, the commit still succeeds. Oboe never blocks git.
2. Metadata lives on a separate orphan branch, not in your code history. Anchor data is written to an orphaned branch (oobo/anchors/v1) using low-level git plumbing commands, so your working tree, index, and code history are never touched. Each anchor is a small JSON file (~1-2 KB) keyed by a commit hash. It doesn’t appear in the git log, doesn’t affect diffs, and doesn’t bloat your master branch. Entries are sharded by hash prefix (similar to Git’s own object storage), so concurrent agents writing anchors never create conflicts.
3. Heavy data stays local by default. Full transcripts, search indexes, token analytics, and cross-project queries all reside in the local SQLite database, not in the repo at all. Only lightweight metadata is synced via Git. Transcript syncing is opt-in (we call it “transparency mode”) and even so, transcripts are reset before they leave your machine.
Net effect: A typical commit adds maybe 50-100ms of overhead and a few KB to a branch you’ll never see live. Your git log, your diffs, your CI are all unchanged.