defract 1.5 and 1.6: your agent can now drive defract, cleanly and safely

Two releases, one story. In 1.5, defract grew an MCP server, so an outside agent can run the full pipeline from scope to merge. In 1.6, we made that connection easy to set up and locked it down. Here is what shipped and why it matters.

1.5: an outside agent can drive the whole pipeline

defract already ran each task through a fixed lifecycle: story, design, architecture, implementation, review, release, with parallel git worktrees and specialist review agents before a gated merge. You drove that by hand in the app. In 1.5 we added an MCP server so an agent can drive it instead.

The agent can live in Claude Desktop, Cowork, or Claude Code. Over MCP it can do the whole job a person does in the app. It can groom the backlog: browse, create, edit, delete, promote, re-groom, and link tasks. It can kick off a task, answer scope questions, and choose the model for each stage. It can approve or send back each implementation phase, inspect diffs, message or stop a running stage agent, and merge the pull request.

The part that makes this real rather than a side door: the MCP path runs the same code as the app's UI. An agent-driven run behaves identically to a hand-driven one. The gates do not move, the audit trail does not fork, and nothing happens through MCP that could not happen through a button. We also renamed the old "autonomous" session mode to "managed," which describes it better. The old name still works, so nothing breaks.

1.6: easy to connect, and safe by default

1.5 made agent-driven runs possible. 1.6 is about making the connection something you set up in a couple of minutes and then stop thinking about, and making sure only you can use it.

one entry for every project

Connect Claude Desktop, Cowork, and Claude Code to all your defract projects with one stable entry. There is a wrinkle worth explaining: Claude Desktop and Cowork cannot dial a localhost address directly. So defract installs a small bridge command that those apps launch locally. One configuration entry then covers every project. The bridge lists your projects and routes each call to the window serving it.

It keeps working when you restart defract or Claude, or switch a window to another repo, with no config edits. You set it once. You do not go back and repoint anything every time a port changes or you open a different repo.

a Settings screen that hands you the config

There is a new Settings, then MCP screen. It shows ready-to-copy setup snippets for each client with this machine's paths already filled in, so you paste rather than hand-assemble. It lists your registered projects. And it lets you rotate a project's connection credential when you want to.

the current transport

The MCP server now speaks the current Streamable HTTP transport, with proper protocol-version negotiation. Claude Code connects with type: http. The older SSE endpoint still works this release, so existing setups do not break, but it will be removed later. If you are on SSE, move over when you get a chance.

a token is required now

This is the security fix, and it is the one to read twice. MCP requests without a valid token are now rejected instead of being granted read access. Before this, another local process could read your tasks, agent logs, memory, or diffs. Now it cannot. Requests from non-local web origins are rejected too. If a request is not local and does not carry the right token, it does not get in.

why the shape of this matters

These releases are not only about convenience. They are about what it takes to hand real work to an agent without handing it the keys to everything, which is the thing we have been writing about in MCP with guardrails. The idea there is least-privilege delegation: scope what an agent can reach, keep a real record of what it did, put gates on the irreversible steps, and make rollback actually work.

1.5 and 1.6 are that idea, built in. The agent gets the affordances a manager needs, start work, approve, send back, merge, but the gates stay where they are and the review agents still run before anything lands. Work happens in worktrees, so an agent's changes sit off to the side until a gated merge, which is reversibility by construction. The MCP path runs the same code as the UI, so the audit trail is the same whether a person or an agent drove. And now the connection itself is least-privilege: a token is required, the credential can be rotated, and non-local origins are turned away. defract stays local-first through all of it. Your code and your terminal transcripts never leave your machine.

The net of these two releases: an outside agent can run your whole defract pipeline, the setup is a short paste from the Settings, then MCP screen, and the door is locked unless you hold the key. Download defract and point your agent at it.