A virtualized filesystem stages agent writes behind `/apply`

Engineer nasutton12 posted a benchmark comparing nine lightweight, mostly self-hosted coding-agent harnesses for modest, resource-constrained hardware: hax, chad, pi, maki, jcode, Reasonix, juggler, clm, and OpenCode. About sixteen hours after posting, the Hacker News thread had 179 points and 70 comments.

Commenter kouteiheika described a private harness with a fully virtualized filesystem built on FUSE. Every file operation an agent makes, including operations from processes spawned through its bash tool, stays staged inside the session until the user runs /apply. The user can rewind or fork a session together with its disk state.

"The agent running rm -Rf /* should be a non-event," kouteiheika wrote. "That doesn't do anything to my filesystem, and can only nuke the agent's view of the filesystem." He called the git-based checkpointing in many harnesses "pretty much useless" because it "doesn't actually give me any guarantees."

Elsewhere in the thread, commenter toasty228 reported that the pi harness used two to three times as many tokens as Codex on a work task involving code review and a fix plan. With a subagent extension installed, pi used eight to ten times as many. This is one practitioner's account, not a controlled comparison.

Why it matters: Kouteiheika has not published the harness or a benchmark of its filesystem design, and toasty228's token figures are also self-reported. If the filesystem design holds up outside the private harness, its explicit commit step may make destructive agent actions reversible at lower cost than wrapping every run in a container. Teams can test that approach alongside sandboxing when evaluating unattended agent workflows.