unf is a background daemon that watches directories you choose (via CLI) and snapshots every text file on save. It stores file contents in an object store, tracks metadata in SQLite, and gives you a CLI to query and restore any version. The install includes a UI, as well to explore the history through time.
The tool skips binaries and respects `.gitignore` if one exists. The interface borrows from git so it should feel familiar: unf log, unf diff, unf restore.
I say "UN-EF" vs U.N.F, but that's for y'all to decide: I started by calling the project Unfucked and got unfucked.ai, which if you know me and the messes I get myself into, is a fitting purchase.
The CLI command is `unf` and the Tauri desktop app is titled "Unfudged" (kids safe name).
How it works: https://unfucked.ai/tech (summary below)
The daemon uses FSEvents on macOS and inotify on Linux. When a file changes, `unf` hashes the content with BLAKE3 and checks whether that hash already exists in the object store — if it does, it just records a new metadata entry pointing to the existing blob. If not, it writes the blob and records the entry. Each snapshot is a row in SQLite. Restores read the blob back from the object store and overwrite the file, after taking a safety snapshot of the current state first (so restoring is itself reversible).
There are two processes. The core daemon does the real work of managing FSEvents/inotify subscriptions across multiple watched directories and writing snapshots. A sentinel watchdog supervises it, kept alive and aligned by launchd on macOS and systemd on Linux. If the daemon crashes, the sentinel respawns it and reconciles any drift between what you asked to watch and what's actually being watched. It was hard to build the second daemon because it felt like conceding that the core wasn't solid enough, but I didn't want to ship a tool that demanded perfection to deliver on the product promise, so the sentinel is the safety net.
Fingers crossed, I haven’t seen it crash in over a week of personal usage on my Mac. But, I don't want to trigger "works for me" trauma.
The part I like most: On the UI, I enjoy viewing files through time. You can select a time section and filter your projects on a histogram of activity. That has been invaluable in seeing what the agent was doing.
On the CLI, the commands are composable. Everything outputs to stdout so you can pipe it into whatever you want. I use these regularly and AI agents are better with the tool than I am:
# What did my config look like before we broke it?
unf cat nginx.conf --at 1h | nginx -t -c /dev/stdin
# Grep through a deleted file
unf cat old-routes.rs --at 2d | grep "pub fn"
# Count how many lines changed in the last 10 minutes
unf diff --at 10m | grep '^[+-]' | wc -l
# Feed the last hour of changes to an AI for review
unf diff --at 1h | pbcopy
# Compare two points in time with your own diff tool
diff <(unf cat app.tsx --at 1h) <(unf cat app.tsx --at 5m)
# Restore just the .rs files that changed in the last 5 minutes
unf diff --at 5m --json | jq -r '.changes[].file' | grep '\.rs$' | xargs -I{} unf restore {} --at 5m
# Watch for changes in real time
watch -n5 'unf diff --at 30s'
Install & Usage:
> brew install cyrusradfar/unf/unfudged
EDIT: Folks are asking for the source, if you're interested watch https://github.com/cyrusradfar/homebrew-unf -- I'll migrate there if you want it.
Thought I'd share the data point to support jetbrains
If an AI agent rewrites 30 files and you haven't touched jj yet, jj has the before-state but none of the intermediate states. UNF* captured every save as it happened, at filesystem level.
jj is a VCS. UNF is a safety net that sits below your VCS.
- UNF* works alongside git, jj, or no VCS at all
- No workflow change. You don't adopt a new tool, it just runs in the background
- Works on files outside any repo (configs, scratch dirs, notes) as it doesn't require git.
W.r.t. to the histogram, this is my fav feature of the app as well. Session segmentation (still definitely not perfect) creates selectable regions to make it easier, too. The algo is in the CLI as well for the Agent recap (rebuilding context) features.
inotifywait -mr -e modify,create,delete /your/dir |
while read _; do
cd /your/dir && git add -A && git commit -m "auto-$(date +%s)" --allow-empty
done
Odds are, one or more people have had this problem in the past and there's probably a nifty solution that does what you want.
I think it would be dishonest if I didn't share that your approach to discourse here isn't a productive way of asking what insights I'm bringing.
If that's your concern, I agree I can't claim that nothing exists to solve pieces of the puzzle in different ways. I did my research and was happy that I could get a domain that explained the struggle -- namely unfucked.ai/unfudged.io -- moreover I do feel there are many pieces and nuances to the experience which give pause to folks who create versioning tools.
I'm open to engaging if you have a question or comment that doesn't diminish my motives, assumes I must operate in your world view "problems can only be solved once", and discourages people to try new things and learn.
Look, I'm grateful that you stopped by and hope you'll recognize I'm doing my best to manage my own sadness that my children have to exist in a world where folks think this is how we should address strangers.
> assumes I must operate in your world view "problems can only be solved once"
Nobody ought to give a damn what I think, the only opinion that matters about you is your own.
But just like I won't ask you adopt my view, I also won't go around patting people on the back for TODO apps.
My opinion: people ought to spend more time contributing to solving genuine problems. The world needs more of that, and less "I built a TODO app" or "Here's my bespoke curl wrapper".
https://gavinray97.github.io/blog/llm-build-cheaper-than-sea...
My comment is not meant as a shallow dismissal of the authors work but rather what seems to be a growing, systemic issue
Git is a convenient implementation detail.
The core loop of "watch a directory for changes, create a delta-only/patch-based snapshot" has been a solved few-liner in bash for a long time...
There are a huge number of people coming into agentic coding with no real background in software dev, no real understanding of git, and even devs with years of experience will readily reach for convenience and polish even when they could otherwise implement it themselves, see: Vercel's popularity.
https://www.vim.org/scripts/script.php?script_id=89
It is comparatively unsophisticated, but I need it so infrequently that it has been good enough.
I do like the idea of maintaining a complete snapshot of all history.
This is a good application for virtual filesystems. The virtual fs would capture every write in order to maintain a complete edit history. As I understand it, Google's CitC system and Meta's EdenFS work this way.
https://cacm.acm.org/research/why-google-stores-billions-of-...
https://github.com/facebook/sapling/blob/main/eden/fs/docs/O...
I spent a bit of time being baffled nothing existed that does this. Then I realized that, until Agents, the velocity of changes wasn't as quick and errors were rare(er)
Writing this, I wanted to ask if the desktop app includes the CLI, but there it says it on your website :-) Thanks for thinking ahead so far, but then picking us up here and now so we can easily follow along into an unf* future!
Looking forward to try it.
> unf watch
# reboot
> unf list
Just one human, two machines at my home can't replicate all configurations...
Keep it up!
Alternative - version files and catalog those versions (most of the work, with "Unfucked", appears to be catalog management), building it on top of a Versioning File System.
E.g. NILFS logging file system, logs every block-change (realtime)
more:
- NILFS https://en.wikipedia.org/wiki/NILFS
- topic https://en.wikipedia.org/wiki/Versioning_file_system
It doesn't read the file the instant the OS fires the event. It accumulates events and waits for 3 seconds of silence before reading. So if an editor does write-tmp → rename (atomic save), or a tool writes in chunks, we only read after the dust settles.
I accept there are cases if the editor crashes mid-state that you have a corrupted state but there was never a good state to save, so, arguably you'd just restore to what's on file and remove the corrupt partial write.
It's not bulletproof against a program that holds a file open and writes to it continuously for more than 3 seconds, but in practice that doesn't happen with text files by Agent tools or IDEs.
Feel free to follow up for clarity.
Why not just use TRime Machine?
+1 for the open source comments.
In your examples the framing of use cases against agent screw-ups is contemporary and well-chosen.
Best of luck with the project as you make it more useable.
I could build an extension for the UI vs a Tauri app, and it could help you install the CLI if you don't have it. Would that meet your needs?
That said, the fidelity of OS-level daemon can't really be replicated from within an app process.
One install, one init, and then it just works. It shouldn't stop across restarts or crashes.
But I'm amused by the people asking for the source code. You trust a tool from a giant corporation with not only your local data, but with all your data on external services as well, yet trusting a single developer with a fraction of this is a concern? (:
I do this but i certainly see the appeal of something better
From what I know (correct me) magit-wip-mode hooks into editor saves. UNF hooks into the filesystem.
magit-wip-mode is great if your only risk is your own edits in Emacs. UNF* exists because that's no longer the only risk; agents are rewriting codebases/docs and they don't use Emacs.
UNF is one install command + unf watch to protect a repo on every file change, takes 30s.
Time Machine snapshots hourly, not on every change, so you can lose real work between snapshots. This may have changed or I missed something but I reviewed that app to see if it was possible.
And while tmutil exists, it wasn’t designed to be invoked mid-workflow by an agent. UNF* captures every write and is built to be part of the recovery loop
https://news.ycombinator.com/newsguidelines.html
Edit: you did it more than once in this thread - the other case was https://news.ycombinator.com/item?id=47183957. Can you please stop posting like this? It's not what this site is for, and destroys what it is for.
I am more interested in testing if folks have the problem and like the shape of the solution, before I try to decide on the model to sustain it. Open Source to me is saying -- "hey do you all want to help me build this?"
I'm not even at the point of knowing if it should exist, so why start asking people to help without that validation.
I work(ed) with OSS projects that have terrible times sustaining themselves and don't default to it bc of that trauma.
Thanks for stopping by.
I love the idea; definitely something I ran into a few times before and wish I had.
Unfortunately, I am not installing a closed-source daemon with access to the filesystem from an unknown (to me) developer. I will bookmark this and revisit in a few weeks and hope you had published the source. :)
I didn't open up the source for this as I have a mono-repo with several experiments (and websites).
Happy to open the source up and link it from the existing website.
I've started to have an Agent migrate it out, and will review it before calling it done. Watch https://github.com/cyrusradfar/homebrew-unf
Edit: You can download the current version now: https://github.com/cyrusradfar/homebrew-unf/archive/refs/tag...
I'd have to imagine that moving this out to its own repo with Claude Code would be trivial so I don't understand the resistance.
This is a great idea. I look forward to seeing a proper repo for it.
Edit: To be clear, I’m not saying any of those things are true, just that those are the first thoughts I have when someone says their source is open but makes it difficult to view. In this age in which it’s so trivial and commonplace to make source easily viewable.
it's just the homebrew cask and recipe.
This does not contain the source.