6 ms·
Diffwatch – Watch AI agents touch the FS and see diffs live
- deemkeen 11mo agoI built a simple TUI that shows live unified diffs whenever files change. It’s useful for TDD, debugging config changes, and watching AI/agents touch the filesystem in real time. Repo: https://github.com/deemkeen/diffwatch https://github.com/deemkeen/diffwatch Install: brew install deemkeen/tap/diffwatch # or go install github.com/deemkeen/diffwatch@latest Try it quickly: # start the TUI diffwatch -r . # in another shell: echo "hello" >> demo.txt; sleep 1; echo "world!" >> demo.txt Why this vs. other watchers? Most watchers tell you that something changed. diffwatch shows what changed, instantly, in a minimal TUI. Roadmap / looking for feedback: --ignore-from=.gitignore, --word-diff, --context N, export (--record, --save-patch), hooks (--cmd "…") GIF in the README. Would love feedback, issues, PRs—especially on ignore patterns and diff ergonomics.
- westurner 11mo agoFrom https://news.ycombinator.com/item?id=45516584#45517613 https://news.ycombinator.com/item?id=45516584#45517613 re: LTM and STM and LLMs: > jj autocommits when the working copy changes, and you can manually stage against @-: https://news.ycombinator.com/item?id=44644820 https://news.ycombinator.com/item?id=44644820 lazyjj is a TUI for jj: https://github.com/Cretezy/lazyjj https://github.com/Cretezy/lazyjj Would a live log follow mode for lazyjj solve?
- deemkeen 11mo agodiffwatch is kinda general purpoure, besides the agent work you could watch different processes doing stuff in your homedir, for example
- westurner 11mo agoCool tool! Is the inotify directory/file watch count the limit? I can't seem to remember the name of the pre-containers tool that creates a virtual build root and traps all the file syscalls. It's not strace. Easier to trace everything an AI runs by running the agent in a container with limited access to specific filesystem volumes. eBPF is the fastest way to instrument in Linux AFAIU: Traceleft: https://github.com/ShiftLeftSecurity/traceleft https://github.com/ShiftLeftSecurity/traceleft Tracee: https://github.com/aquasecurity/tracee https://github.com/aquasecurity/tracee Falco docs > Supported events: https://falco.org/docs/reference/rules/supported-events/ https://falco.org/docs/reference/rules/supported-events/ Tetragon: https://github.com/cilium/tetragon https://github.com/cilium/tetragon strace could have a --diff-fs-syscall-files option: strace -p PID -f -F -e trace=file -s 65536
- deemkeen 11mo agoit uses the os independant fsnotify lib, it surely has its limits. eBPF is great, but linux only, yeah
- westurner 11mo agoOn MacOS: sudo dtrace -n 'vfs::*:entry { printf("%-16s %-6d %s", execname, pid, probefunc); }' sudo dtrace -n 'vfs:lookup:entry { printf("%-16s %-6d %s", execname, pid, copyinstr(arg1)); }' TIL Dtrace is included in recent builds of Windows 11 and Server 2025: https://learn.microsoft.com/en-us/windows-hardware/drivers/devtest/dtrace https://learn.microsoft.com/en-us/windows-hardware/drivers/d... ; # Must be run as Administrator dtrace -n "syscall::NtCreateFile:entry, syscall::NtReadFile:entry, syscall::NtWriteFile:entry { printf(\"%s (%d) - %s\", execname, pid, probefunc); }" It's possible to trace file system calls in Windows with procmon.exe by saving a .pmc config file and then loading it from the CLI: procmon.exe # uncheck everything except "Show File System Activity" # Filter > Drop Filtered Events # File > Export Configuration... # Must be run as Administrator procmon.exe /AcceptEula /Quiet /Minimized /LoadConfig C:\Tools\fs-only.pmc /BackingFile C:\Logs\FileSystemTrace.pml It's also possible to trace lower level file system calls in Windows with logman.exe but it's necessary to parse the traces that it generates. Then with just bpftrace on Linux: sudo bpftrace -e 'tracepoint:syscalls:sys_enter_openat { printf("%-6d %-16s %s\n", pid, comm, str(args.filename)); }' sudo bpftrace -e 'kprobe:vfs_read, kprobe:vfs_write, kprobe:vfs_open { printf("%-16s %-6d %s\n", comm, pid, probefunc); }' ... According to 2.5pro on the cli strs strace, dtrace, and bpftrace could have a --diff-fs-syscall-files option.
- deemkeen 11mo agogreat insights, i'll read up on it and see if it can be useful, thx
- westurner 11mo agonp. there's a diagram, "Linux bcc/BPF tracing tools" [-1] in the bcc readme [0] that's also in [1] which explains ebpf and bcc and bpftrace. filetop, dirtop, and vfsstat use bpf to trace the VFS layer. [4] [-1] "Linux bcc/BPF tracing tools" https://www.brendangregg.com/BPF/bcc_tracing_tools_early2019.png https://www.brendangregg.com/BPF/bcc_tracing_tools_early2019... [0] iovisor/bcc: https://github.com/iovisor/bcc https://github.com/iovisor/bcc [1] "Linux Extended BPF (eBPF) Tracing Tools", Dtrace book: https://www.brendangregg.com/ebpf.html https://www.brendangregg.com/ebpf.html If running an AI agent in a container --- with devcontainers and e.g. vscode, Good container policy prevents granting a container the CAP_SYS_ADMIN capability; the least-privileges thing to do is to grant limited capabilities to the container like CAP_BPF and (CAP_PERFMON, CAP_NET_RAW, CAP_SYS_PTRACE) [,3]. [3] https://medium.com/@techdevguides/using-bpftrace-with-limited-capabilities-inside-docker-a-capability-focused-guide-851695a13197 https://medium.com/@techdevguides/using-bpftrace-with-limite... [4] bpfcc-tools manpages: https://manpages.debian.org/unstable/bpfcc-tools/index.html https://manpages.debian.org/unstable/bpfcc-tools/index.html though ripgrep wins, vscode fails at monitoring large workspaces due to inotify limits too; so some way to parse fs events from bcc and libdtrace with python would be great prompt 1: Create a python project named idk dbpftrace with a pyproject.toml and a README and sphinx /docs, with bcc and python-dtrace as dependencies to, then in dbpftrace/, parse pid and descendents' fs syscall events from bcc (ebpf) or python-dtrace (dtrace), depending on which os we're running Edit: Prompt 1B: Create a Go package named dbpftrace with a README and docs, parse pid and descendents' fs syscall events from bpftrace or dtrace stdout, depending on which os we're running