OpenMozi

The deciding trait is what it asks you before it starts. Folder, branch, permission level and model are all chosen in the same place, so the answer to what can this thing touch is decided by you rather than discovered later. Most tools in this class ask nothing and inherit whatever directory you happened to be standing in.

The price is friction at the start of every task, and a young project underneath the ceremony. Pick it if you want the boundaries explicit. Pick a terminal agent if you would rather just start typing.

Scheduling is where this gets dangerous. A task that repeats is a task nobody is watching, and the permission ladder tops out at unrestricted, so the worst configuration available is also the most convenient one to leave in place. Nothing in the row constrains what a scheduled run at that level may reach on the machine.

What it does right is the git behaviour. The branch switch never stashes silently and never forces, which means your uncommitted work is not collateral in a tool that otherwise moves quickly.

1. Agents overwhelmingly fail by asserting work they did not perform, and the standard remedy is asking the model to be careful. Checking the artefact against the filesystem instead moves the test outside the model, which is the only place a verification can be trusted. 2. It is a narrow check, confirming existence rather than correctness, and narrow is still categorically better than none.

2. No evaluation is published. The design argument here does not require one, since the mechanism is inspectable directly.

Being described as inspired by something more famous sets the ceiling. The comparison is the first thing a buyer makes, the original owns the name, and the derivative has to be better rather than merely similar to win anyone. Two hundred stars is interest in the idea, most of which the inspiration already captured.

Moat: none, and the reference to a better-known project makes that structural. Likely path: it remains a personal reimplementation and the audience returns to the original. Position: run it if the differences matter to you, and expect no support.

Persistent memory is the line that stops this. Something on a developer's machine is accumulating information about our codebase across sessions, and I have no statement of what is stored, for how long, or where it goes when the laptop is returned. That is a question our retention policy asks and this row cannot answer.

Beyond it: no directory integration, no provisioning, no central audit, no unattended pipeline role and sixty separate installations to keep current. Onboarding is quick. Not yet, and the first requirement would be a written statement of what the memory holds.

The licence is right and the source is there, so the fork is mine and the claim to be hackable is at least legally true. Any provider key works. Beyond that the word is doing more work than the row supports: there is no documented install path, so building from source is the only route in, and I have to reverse-engineer the setup before I can start changing anything.

No MCP client, so my servers stay outside, and no local endpoint, so a desktop tool that never leaves my machine still sends every token off it.