6 posts tagged “daemon”.
8 min
One daemon, three clients, a long-lived stream of terminal output running alongside ordinary request/response calls. The protocol that carries all of that is gRPC over loopback TCP. Here is the honest accounting: the four alternatives we steelmanned, what the .proto actually looks like, how a client opens the connection, and the costs we took on to get schema-first generated clients in two languages.
6 min
The 7.2 → 7.3 arc is a tidy little story about operability. We made the daemon log durable, the durable log grew to 300 GB, and 7.3 caps it. Along the way we closed two wildfire YAML bugs that were silently eating tasks, and gave the GUI a focus-chat mode. Here's what shipped.
6 min
When a task gets stuck, the answer is almost always in watchfired's log. Here is where it lives, what its lines actually look like, and the five events plus three walkthroughs you'll reach for when an agent won't start, a worktree won't spawn, or an auto-merge never fires.
7 min
The happy path is easy: the agent works, sets status done, the daemon merges. This is the other path. The PTY dies, the agent stalls, the sandbox kills it, the daemon restarts. Here is what Watchfire actually does — and what it leaves for you to do — when a run goes wrong.
9 min
There is a binary called watchfired, it runs in the background, it talks gRPC to three clients. The first reasonable question is: why does this need a daemon? Here is the long answer.
10 min
Watchfire's UI feels reactive because the daemon never sleeps on its files. The canonical state of every project lives on disk, agents 'complete' a task by saving a YAML, and a debounced watcher fans the change out to every connected client. Here is the architecture, the trade-offs, and the edge cases.