The malleable operating system that grows with you, and has to prove every change before it makes it.
Moos is an operating system you talk to. Its apps take plain language, and when one is missing the feature you had in mind, Moos offers to build it: a short brief, your yes, then a supervised build run in its own git worktree that has to prove itself before it may change anything. It lands as one commit, so undo is one revert.
Underneath is one Go daemon and a browser tab: a desktop with header, dock and window manager, and about forty apps, among them chat, terminal, editor, finder, browser, mail, calendar, paint, a spreadsheet and a workflow canvas. Every app is a supervised Go backend with a plain web UI and a manifest. Everything is local and everything is git: data lives in a versioned partition that keeps every revision, rights sit in a permission store that asks before it grants, and the claude or codex CLI runs as you, on your machine. No account, no cloud service.
A claim in the transcript proves nothing.
An agent, an environment, and a grader that does not take its word for it
Seen from the inside, Moos is an environment for a coding agent with a grader attached, and it is built around the question every environment and every eval has to answer: what should the system refuse to accept as proof? The answer it settled on is that only what the host watched happen counts. A build run cannot reach its audit phase until the host has seen go test ./... exit green, and cannot deploy until a security scan has run over the real diff. The phases are forward-only. How far a change reaches is read from its diff, not from the agent’s account of it, and a run that touches the desktop shell or the host machine drops to guided mode and waits for a person, whatever autonomy it was given.
What a thousand commits by Claude Code agents taught me
Moos itself was built the same way. Since August 2026, several Claude Code sessions have worked on one repository in parallel: each in its own git worktree, one acting as integration coordinator, merges serialised and announced, every piece of work an issue on a Markdown board that the system’s own Board app displays. That is 1,072 commits and 258 issues so far. The instructive bugs were rarely in the code the agents wrote. They sat in the seams, wherever a check trusted something it should not have:
- Silence read as success. A build run ran out of turns. The CLI still exited 0, with an empty result, and the host recorded the run as done. A complete app sat unmerged on a branch while, from the outside, the Builder had simply never worked. The fix: the absence of an error is not evidence of success, and “this run failed” and “this run cannot be read” are two different answers.
- A screen that arrived in fragments. A probe waited for a terminal UI’s first output, then typed a command. Under load, it typed into a trust dialog that was still being painted. The lesson: reading a screen gives you absence of evidence, and no timeout makes that sound. The guarantee moved to a structural precondition, and the screen check stayed only as a second line of defence.
- Checks that look too early. Tests that waited for a signal which precedes the thing they assert, and so passed or failed depending on scheduling. Waiting for the asserted thing itself fixes it. A longer sleep is the same bug with better odds.
- Load is a signal, not noise. Four flaky tests in four packages traced back to one cause: the test gate asked for more parallelism than the machine had. The gate is bounded now, and a deliberate unbounded run is kept on purpose, because load is exactly what exposed the trust-dialog bug.
These are the classic failure modes of environments and graders in miniature: reward that arrives without the work, an observation captured half-rendered, a check that passes because it looked at the wrong moment. Most of building Moos was the craft of closing them one at a time, and of writing each one down so the next session would not reopen it.
Written in Go, built almost entirely by Claude Code sessions, with me writing the requirements, reading the briefs and deciding what counts as proof. The name is German for moss: it grows over whatever ground it finds, without a plan. The landing page keeps an honest list of what runs today and what does not, including the weakest part of the design so far, composition between apps.