Building a world-class daemon

Most of what RepoOps promises depends on one small program you never think about: a background agent that captures your Claude Code work and keeps your dashboard current. Proof of what your AI shipped, what it cost, what it learned. None of that can be always-current unless something is always-on, quietly, without a server running and without you remembering to refresh anything.

That program is the capture daemon. It is the least glamorous part of the product and the one everything else stands on. So we did the thing you do with load-bearing infrastructure: we audited it against the daemons the industry treats as the reference points, one axis at a time, and we were honest with ourselves about where it fell short.

Why a background agent is the quiet foundation

A dashboard that is only current when you open it and wait is not proof. It is a report you have to run. The whole point of RepoOps is that the receipts are already there: the accountability ledger, the cost views, the nightly brief. That only works if capture happens on its own, survives a laptop-lid-close and a reboot, and needs no server process babysitting it.

So the daemon has a simple job with a high bar. Capture every session within a few minutes. Keep the heavy views warm so the dashboard opens instantly. Run the nightly learning pass so you wake up to a brief. And do all of that without ever becoming a thing that can break, leak, or nag.

What "world class" means for a daemon

We measured the daemon on five axes, using the daemons that define each one as the yardstick:

• Supervision. Does the operating system own start, restart, and rate-limiting, the way it does for a well-written service?
• Security. How small is the attack surface, how little privilege does it hold, and how carefully does it handle your data?
• Performance. Does it govern its own memory instead of growing until something kills it?
• Fault tolerance. When something goes wrong, does it recover on its own, and does it ever lie about its own state?
• Updates. Can it update itself without ever running code it did not verify?

Here is where we landed, honestly.

The things we are already proud of

Some of this the daemon got right from the start, and it holds up against anyone.

• No inbound port. The daemon never listens for a connection. It only makes outbound calls, and only after you opt in. There is no remote surface to attack, because there is no door.
• Inert by default, with redaction at the point of writing. It sends nothing until you bind a device and turn on sync. And what it keeps is redacted before the line is ever written to disk, not scrubbed later. That is a stronger privacy default than the usual monitoring agent, which starts full egress the moment it has a key.
• Daemon-optional correctness. This is the property we are proudest of. Every view still computes on demand. The daemon only pre-fills. So a stopped daemon makes RepoOps slower, never wrong, and never down. Most agents are a single point of failure for the feature they power. This one is not.
• Honest status. The daemon marks itself stale the instant it stops. It stamps a push time only when data actually left the machine. Its status command checks that the process is really alive before it claims to be running. It will never show you a frozen number dressed up as live.
• Supervision the OS owns. It installs as a launchd agent on macOS, a systemd service on Linux, and a Scheduled Task on Windows, so auto-start and auto-restart are handled by the platform, not a bundled supervisor that rots.

What we added to reach world class

The audit found real gaps. We closed them.

• Signed, staged, self-healing updates. A background agent that can update itself has to earn that cryptographically. The update model verifies a signature and a content hash before a single byte is trusted, stages the new version beside the old one, rolls out to a slice of the fleet first, and rolls itself back automatically if a fresh version starts crash-looping. No unsigned bytes ever run. We describe the mechanism rather than promise a date, because the shape of the trust model is the point: verify first, stage, widen gradually, roll back on trouble.
• Device identity that expires and rotates. Each device carries its own token, not a shared secret. The identity model provides for tokens that expire and rotate in place with no capture gap, and for a team owner or admin to revoke any device.
• Operating-system sandboxing and Linux watchdog liveness. The generated Linux service runs with restricted privileges and uses the OS watchdog, so a fully wedged process is caught and restarted in minutes. On Windows the daemon tightens the access control on its own data directories. On macOS it runs as a low-priority background job.
• Crash forensics and a one-command support bundle. A fatal crash now leaves a diagnostic report on disk. And a single command produces a redacted support bundle with secret values masked, so you can send us what we need to help without leaking anything.
• One unified data path. There is one daemon codebase, and it feeds both the local app and the hosted dashboard through a single seam into one shared rollup substrate. The hosted dashboard reads the same finalized rollups the daemon produces, with a version handshake so a reader never serves a payload shaped for a different version. No bespoke second aggregation to drift out of sync.

What it means for you

The value of a good daemon shows up differently depending on where you sit.

If you use the local app as a solo developer, it is zero effort and it disappears. Capture is automatic and always warm, so the dashboard opens instantly instead of parsing your whole history. You wake up to a nightly brief. And it is private by default: nothing leaves your machine unless you decide to connect a team.

If you use the hosted dashboard, you get a live fleet view of every device running the daemon: which are healthy, which are behind on version, and an alert when a device that should be reporting goes dark. You stop wondering whether capture is actually on across the team, because you can see it.

If you run a team, every developer's daemon rolls up into one team view. Shared lessons compound. Cost attributes per developer, per repo, per merged change. A new hire's daemon starts feeding the same pool on day one. One substrate, one picture.

And for organizations and leadership, the layer above team is coming. It groups teams into an organization, gives you an org-wide daemon fleet view across every member team, and rolls the numbers up into a leadership cockpit: total capture coverage, cost, benefit, and prevented incidents summed across every team, with drill-in per team. Because the local app, the team, and the org all read the same substrate, that executive rollup is a straight sum of what every daemon already produces, not a separate pipeline to trust.

One daemon, from a laptop to a leadership cockpit

The direction is a single idea carried all the way up. The same daemon that keeps one developer's dashboard warm is the daemon that feeds a team's shared brain and, above that, an organization's executive rollup. One codebase, one data path, one honest picture of what your AI is doing, from a single laptop to a company-wide view.

That is what a world-class daemon buys you: not a feature you notice, but a foundation you can stop thinking about. It captures, it stays current, it tells the truth about itself, and it never becomes the thing that breaks.

If you want to see it, install RepoOps and read the capture daemon docs.