Moos

Ask Moos for something it cannot do, and it offers to build it.

Moos is an operating system that boots to a browser desktop. When it has no answer for you, it does not apologise and it does not improvise. A dialog opens — the same family as a permission prompt — carrying a short brief: what it would build, which rights it would need, and what it explicitly would not do.

You press yes, type a correction to have the brief rewritten, or decline. Accepting starts a supervised build run in its own git worktree. It has to prove itself before it is allowed to change anything, it lands as a single commit, and taking it back out is one revert.

The proposal dialog, drawn here in this page’s own styling. The real one lives in the desktop shell and can be reached from a text box inside any app, from the dock, or from chat.
Run it on your machine Source on GitHub Go and git, one binary, no account.

What happens when you say yes

A build run is a bounded, watchable unit of work, not a black box. The Builder app shows where it is; a brain icon sits in the dock and the header for as long as something is being built, whether or not a window is open.

  1. brainstorm
  2. design
  3. implement
  4. test
  5. auditneeds green tests
  6. deployneeds a diff scan
  7. done

The sequence is forward-only. The two filled marks are gates: the run stops there until the host has seen the proof itself.

It runs on evidence, not on its own report

No auditing without a green go test ./.... No deploying without a security scan over the real diff. Both are things the host watched exit. A claim in the transcript proves nothing.

Reaching further is not the run’s decision

A build that touches the desktop shell or the host machine drops to guided mode whatever you configured — decided from its own diff, not from its own account of itself.

You choose how close to stand

Autopilot reports when it is done. Guided stops twice: to approve the plan before code exists, and the merge before the system changes. Granular stops at every step.

Undo is one button

The run lands as a single merge commit, so taking it back is one revert and a rescan. If the new app has produced data in the meantime, Moos asks separately whether that should go back too.

a recording of one build run goes here /media/build-run.mp4
Roughly thirty seconds: the ask, the brief, the phases moving, the merge, and the new app opening from the dock.

The system underneath

moosd serve plus one URL gives you a desktop: header, dock, window manager. Every app is a supervised Go backend with a plain web UI and a manifest, so the system stays inspectable and gets faster as it grows. Roughly thirty apps ship with it — chat, terminal, editor, finder, browser, mail, calendar, paint, spreadsheet, a workflow canvas and the rest — and they are the ground the loop grows on, not the point of it.

Everything is local and everything is git. Data lives in a versioned partition where every revision is kept, rights are held in a permission store that asks before it grants, and the claude or codex CLI runs as you, on your machine. There is no account and no cloud service to sign up for.

The Moos desktop in a browser: a header with alarm, timer and clock, a dock along the bottom, and the Workflows canvas, Calendar, Paint and World Clock apps in overlapping windows.
The desktop with the Workflows canvas mid-edit, and the header’s alarm and timer fed by real host scheduler entries.

Depending on why you’re here

You build operating systems

The interesting part is not the code generation, it is the harness: what a system must prove before it is allowed to change itself. Forward-only phases, evidence the host observed rather than evidence the model reports, reach read from the diff, one merge commit so undo is one revert.

The architecture document is the binding contract.

You care about malleable software

Modification happens in the context of use. The ask can come from a text box inside any app, from the dock, or from chat — you never open a development environment, because there isn’t one to open.

Where it falls short, honestly: a run takes minutes, not milliseconds, so this is not the direct-manipulation immediacy the term usually means. And composition between apps is the weakest part of the design so far.

You work with LLMs

A compiler is deterministic; a model is not. So the system does not bootstrap on trust, it bootstraps on evidence. The question Moos is built around is what a system should refuse to accept as proof — and what it does when the answer turns out to be wrong anyway.

The requirements it grew from.

You just want to try it

One go build, one serve, one URL. The desktop boots without any AI configured — you get the apps, the window manager and the versioned data partition, and the Builder simply stays off until you log in to an LLM CLI.

The three commands.

What runs today, and what doesn’t

Moos is being built in the open and this section is kept honest on purpose. As of September 2026.

Runs today

  • The host daemon, the desktop shell, the app model and the launcher.
  • The versioned data partition and the permission store with its ask flow.
  • The base-app colony, SQLite and embeddings, and the header’s system controls reaching the real machine.
  • The whole loop above: gap detection, the brief, the proposal dialog, the Builder, the forward-only phase machine with its evidence rules, reach escalation, deploy and undo.
  • Reading its own error log: a crashed backend’s stacktrace, scattered over thirty ring entries, is collected back into one fault and offered to you as a repair through the same gated run.

Not yet, or not at all

  • Composition between apps. They are components with manifests, but there is no real story yet for wiring one into another.
  • Immediacy. A build run is minutes of work, not a direct-manipulation gesture.
  • Go 1.25 and git have to stay on your PATH at runtime — each app compiles on first launch.
  • Without a logged-in claude or codex CLI the desktop boots, but chat and the Builder are disabled.
  • One machine, one person. Moos binds to localhost and is not built to be exposed to a network.

Run it

You need Go 1.25 or newer and git on your PATH, a modern browser, and — for chat and anything that builds — a claude or codex CLI you have installed and logged in to yourself. 

$ git clone https://github.com/salam/moos.git && cd moos
$ go build -o bin/moosd ./cmd/moosd
$ ./bin/moosd doctor        # checks Go, git and the LLM CLI
$ ./bin/moosd build         # optional: precompile the app backends
$ ./bin/moosd serve

serve prints exactly one line: a one-time bootstrap URL. Opening it sets a session cookie and burns the token. That session auth is mandatory and cannot be switched off — without it, exposing the port would be remote code execution.

Questions people ask first

Isn’t this just a code generator with a window manager?

That is a fair first reading, and the difference is what the system refuses to accept as proof. Code generation is the easy half. Moos is built around the harness: the phase sequence is forward-only, auditing will not start without a green go test ./..., deploying will not start without a security scan over the actual diff, and both are results the host watched exit rather than claims in a transcript. A build that reaches into the shell or the host is forced into guided mode by its own diff. And the whole run lands as one commit, so a wrong answer costs one revert.

What stops it from breaking the system it is running on?

Four things, in order. It works in its own git worktree, so nothing is touched until a merge. It cannot reach the audit or deploy phase without evidence the host itself observed. Any diff touching the desktop shell or the host machine escalates to guided mode and waits for you. And the merge is a single commit, so undoing it is one revert plus a rescan — with a separate question about any data the new app produced in the meantime.

Does my data or my code go anywhere?

Moos itself runs entirely on your machine: a local daemon, a local browser tab, local git, no account and no service to sign up for. What does leave is whatever the claude or codex CLI sends to its own provider when you use chat or a build run — that CLI is installed and logged in by you, runs as you, and is governed by your agreement with that provider. Without it the desktop still boots and stays completely local.

Which model does it use, and what does it cost?

Moos does not talk to a model API directly. It drives whichever LLM command-line tool you already have — currently claude or codex — so the model, the plan and the bill are whatever you already pay that vendor. Moos is free and its source is public.

What if the app it builds is wrong?

You reject the brief before anything is built, correct it in the dialog and have it rewritten, stop the run at a phase boundary in guided or granular mode, or revert the merge commit afterwards. The design assumes the answer will sometimes be wrong; the point is that being wrong stays cheap.

What does the name Moos mean?

Moos is German for moss. Moss grows over the ground it finds, slowly and without a plan, and the system is meant to grow the same way: apps accrete, the desktop is the ground, and nothing needs to be designed up front. The repository’s own documents follow the metaphor — the seed, then the protonema, then the growth.

Who is behind Moos

Moos is built by Matthias Sala, a software engineer in Zurich.

He studied computer science at ETH Zurich and worked there as a teaching assistant — with Jürg Gutknecht, whose group built the Oberon language and the Bluebottle operating system, with Thomas Gross on compilers, and with Bertrand Meyer on Eiffel and design by contract. His semester project was Kulula, a component-oriented compiler for Bluebottle. After ETH he worked on embedded smart systems at Siemens Corporate Technology, and researched context-aware information targeting at Xerox PARC.

Moos is the old question from those rooms, asked of a new machine: how much of itself may a system rewrite, and what does it have to prove first.

More of his work: matthias.sala.ch.