I've been staring at terminal output from cargo watch runs for the better part of a decade, so when I saw Funzzy's v2.0.0 drop with the tagline "one reliable edit loop for developers and coding agents," my first reaction was skepticism. Another watcher? With agent hooks? Sure.
But after spending a few evenings reading the source, the docs, and the recent commit history (the maintainer has shipped something almost every day in early September 2026), I'm genuinely impressed. This isn't a thin wrapper around notify with a YAML DSL bolted on. It's a deliberate rethink of what a watcher should do in 2026, when the "user" hitting save might be a human or a Claude session, and both of them need the same thing: a reliable, addressable result.
Let me walk you through what Funzzy actually does, what's good, and where I'd push back.
What it does, minus the marketing
At its core, Funzzy is a file watcher + workflow runner written in Rust. You drop a .watch.yaml in your repo, declare jobs (shell commands), and Funzzy runs them when matching files change. That's been the table-stakes pitch since make watch was cool. Where v2 diverges is the runtime contract.
Every batch of file events gets a monotonically increasing generation number. Jobs that fire in response become an ordered plan with a known identity. The result is addressable by generation. There's a Unix control socket (.tmp/funzzy/control.sock) that lets any local process — terminal, editor, agent — query status, stream output for a specific run, or cancel a specific run by its generation. No log scraping, no grepping the terminal, no "is it done yet, or did it crash?"
The YAML is deliberately small. Jobs can be finite commands, parallel groups (parallel: checks), or long-running services with a readiness check (run: curl --fail http://...). Concurrency, timeouts, and a "busy policy" (wait or replace) are all first-class. There's a JSON Schema you can print with fzz config schema, and the parser refuses to silently accept ambiguous configs.
The maintainer kept the v1.x line around on a separate branch with a migration guide. The fzz migrate command converts accepted old configs to the jobs: form. That's the kind of care you only see when someone has actually been burned by their own breaking changes.
Why this matters now
Here's the thing: the entire cargo watch / entr / watchexec ecosystem was built for a single user model — a human at a terminal who can see colored output and infer state. That model is breaking.
When an LLM coding agent runs your test suite, it can't look at scrollback. It needs a structured response: did this exact run pass or fail, what's the failure tail, can I cancel it without leaving zombies. Funzzy's fzz ctl status --format toon and fzl ctl output --generation 12 --tail 80 are exactly the primitives an agent wants. The TOON output format keeps tokens lean.
But — and this is the part I appreciate — the author didn't build this only for agents. Ctrl-G in the terminal still kicks off all jobs. The same YAML works in CI. The same control socket works for editor integrations. It's the same loop, just with a stable address. That's a much harder design problem than "agent SDK" or "human UI," and Funzzy took the hard path.
The ecosystem timing helps. As I write this in 2026, every serious editor and agent framework is bolting on "run my checks" features. Funzzy arrives with a 10-year-old v1 codebase and a v2 rewrite that is explicitly positioned at this gap. The topics list — agentic-coding, cli, dx, watcher — tells you exactly who they're targeting.
Five things it does that made me nod
1. Generation-based run identity. Every triggered batch is an integer you can hold in a variable, query by, and cancel by. This sounds trivial until you try to debug a watcher where two runs overlap and you don't know which output belongs to which save.
2. Process-group cancellation with timeouts. When a job times out or gets cancelled, Funzzy reaps the complete process group, not just the top-level PID. If your test runner spawns a subprocess that spawns a subprocess, they all die. This is the single most common footgun in homemade watcher scripts, and it's solved at the runtime level.
3. Service jobs with readiness gates. A service: true job can stay alive indefinitely, but only after a readiness probe passes. So you can have cargo run spin up your dev server, wait for the /health endpoint to respond, and then keep the server running while subsequent jobs (or the next edit) execute against it. Most watchers force you into a separate process supervisor for this.
4. Reload-on-config-change, with refusal on bad YAML. Edit .watch.yaml, save, and the watcher hot-reloads the new plan. Edit it again with invalid YAML, and it stops with a clear error rather than silently running the old plan forever. Small detail, big quality-of-life win.
6. A control socket as a stable API. The Unix socket at .tmp/funzzy/control.sock is the abstraction layer. Whether you're an LSP server, a tmux status bar, or a coding agent, you speak the same protocol. The maintainer publishes an agent config contract document so clients don't have to guess.
Who should actually use this
Yes, switch if:
- You're running Rust services with a hot-reload loop and you want a single YAML for cargo run + cargo test + cargo clippy.
- You're building an editor plugin or agent harness that needs a programmatic way to drive checks.
- You're tired of make watch shellscripts that leak zombie processes on Ctrl-C.
- You want service mode with readiness checks (e.g., spin up a Postgres container, wait for it to accept connections, then run integration tests against it).
Stay on watchexec / entr / cargo watch if:
- You need a single-binary, zero-config watcher right now. Funzzy wants a .watch.yaml. If your team balks at one extra file, the friction isn't worth it.
- You depend on a plugin ecosystem. watchexec has a richer plugin story; entr is a single C file. Funzzy is opinionated and small on purpose.
- You're on Windows. Funzzy leans heavily on Unix semantics — Unix sockets, process groups, signals. There's a Linux script and Nix support, but I didn't see first-class Windows in the docs. Caveat: I may have missed it; check the installation guide before committing.
Honest concerns
The 293 stars and 11 forks are modest for a tool with this much ambition. The project is essentially a one-person operation — cristianoliveira has 1,045 commits versus the next contributor's 4. That's a bus factor of 1, and it shows up in places: the commit log references internal task IDs (TASK-0169, TASK-0164, TASK-0062) that suggest a solo project-management system rather than public issue tracking. If you're betting a team's CI on this, factor in the key-person risk.
There are only 2 open issues, which sounds healthy until you realize that's the public-facing count — a lot of the actual work tracking happens in the commit messages themselves or in plans/ directories that aren't published to crates.io (the Cargo.toml explicitly excludes them). That's fine for a solo maintainer, but it makes community contribution harder. I couldn't easily find a public roadmap or a "good first issue" list.
The MSRV is pinned at Rust 1.97, which is bleeding-edge. If your team is on stable, you may need a recent toolchain. The Cargo.toml comments mention keeping this in sync with the Nix toolchain and CI pins, so it's at least deliberate.
The Cargo.toml also has an interesting choice: syn is a dev-dependency used to "parse Rust syntax for architecture-boundary tests." That's a sign the author is using tests to enforce module boundaries, which is admirable, but it's an unusual dependency for a watcher. It tells you this project is more architectural-experimental than its small footprint suggests.
Lastly, the migration path from v1 to v2 is real but you'll feel it. The DSL changed. If you have a sprawling .watch.yml already, you'll be touching it. The fzz migrate tool helps, but plan for an afternoon.
The verdict
Funzzy v2 is the first watcher I've seen that takes the agent-coding transition seriously without turning into an "AI tool" in the cringe sense. It's a well-engineered Rust binary with a clean separation between the watcher, the plan, and the control protocol. The generation-number trick alone justifies the install if you're driving checks from anything other than eyeballs.
If you're a solo developer who just wants cargo watch, stick with cargo watch. But if you're building tooling around the edit-run-inspect loop — for yourself, for an editor, for an agent — Funzzy is the most thoughtful implementation I've seen in 2026. It's MIT-licensed, it's a single cargo install away, and the maintainer is shipping daily.
I'd give it a solid recommend with the caveat that it's a one-maintainer show. Use it, but don't build a team-critical workflow around it without a fallback.
Repo: github.com/cristianoliveira/funzzy
Install: cargo install funzzy (or brew install cristianoliveira/tap/funzzy)