The thinnest harness that can rewrite itself.

$ curl -fsSL https://raw.githubusercontent.com/GSequist/microcc/main/install.sh | sh
> irm https://raw.githubusercontent.com/GSequist/microcc/main/install.ps1 | iex

powershell. installs inside wsl, so run wsl --install first if you have none.

malleable

the harness is the code

Most agents extend through a plugin API — a fixed set of hooks the harness author chose to expose. micro·cc ships as plain, readable Python instead. No compiled binary, no build step: the running process is the files on disk.

Ask for a change in words and it edits its own source, restarts into it, and comes back changed. That works on any install — a dev checkout, or a pip, pipx, brew or uv install on macOS, Linux or WSL — and every fresh install is told in its own system prompt that it can do this.

Editing the package is also the fragile way: the next update replaces the file. So what you add for yourself lives outside it — a mod in ~/.micro-cc, where pip never installs. One file, one register(on), and your handlers ride the same event bus the built-in interface runs on: commands, keys, glyphs, and every component on screen. The built-in behaviour is still underneath, one nxt(e) away, so you decide whether to wrap it or replace it.

orchestration

subagents that are peers, not children

A subagent is another full instance of the same harness: its own project directory, its own durable conversation, the same tools and skills. One shell call starts it, and it announces itself to the session that spawned it the instant it comes up — no manifest, no registration API.

Status is read from the child's own transcript, and a checkpoint arrives as a real new turn rather than a poll. Sessions message each other directly, and a paused child resumes its exact history.

the whole of it

a loop that rewrites itself

A harness is a loop: the model asks, the machine answers, around again. micro·cc is that loop in plain Python with nothing sealed around it, so the file it runs from is a file the model can open and edit.

When it does, micro·cc waits for the turn to end, re-executes in place under the same process id and rebuilds the conversation from disk. If the new code will not boot, a small supervisor reinstalls the published release.

~/.micro-cc/ your additions, untouched SELF_HEAL_ model machine claude_loop_.py the file it is running between turns the model edits its own file ↻ it restarts in place same pid · same conversation now it can do something new ✗ the new code will not boot ↻ the release is put back at most three tries ↻ it restarts in place same pid · same conversation + retry on error

mods

and anything around it, redrawn

A mod is a file outside the package that hooks part of the interface by name. Both lines under the input, the banner, the header, any single message row, the whole glyph set — or a pane of its own, which is what this is.

The mind mod draws what the next call will carry: the context split between memory, summary and window, every message as a cell with the folded bulk, the cut region and the live edge marked, the fold meter, the rolling summary, and all eighteen memories with their ages.