I did a thing last week that I suspect a lot of us do. I sat with Copilot CLI for an hour, planned out a change to some Bicep, and ended up with a transcript about four screens long. Somewhere in the middle the agent asked whether to keep the old storage account naming or move to the new convention, and I answered. Then I pasted the whole lot into Teams so the team could see it. Two people kindly chipped in with thoughts, I agreed with one of them without noticing it contradicted what I’d already told the agent, and a day later when I went back to find what we’d settled on, I honestly couldn’t. The code got written anyway. The naming was wrong, and it was my doing.
That is the problem Chopin is poking at, and it’s the GitHub Next project I’m most looking forward to getting my hands on. This post is what I’ve learned from reading the project page and the repo, and why I’m planning to spend a weekend self-hosting it.
What it is#
GitHub Next describes Chopin as “a real-time multiplayer, agentic planning environment”. Strip the adjectives and it’s a shared document, tied to one GitHub repository, that a team and an agent write together. The document is an implementation plan, a spec, an RFC, a decision record, that sort of thing. When the plan is agreed, a coding agent picks it up and does the work.
It’s a research prototype, published in September 2026 by Krzysztof Cieślak and Maggie Appleton, and the source is on GitHub at githubnext/chopin under MIT. The project page is unusually blunt about its state: “Chopin is neither a product nor a finished prototype. We don’t recommend you attempt to use it today.” It then says that within a month or so they expect to be ready for alpha users. That was written around September, so by the time you read this the creases may be ironed out, or they may not. I haven’t found a sign-up form, and the README says there’s no public instance, so for now the only route in is running it yourself.
If you followed GitHub Next’s earlier work, Chopin is described as the spiritual child of Ace, which is now paused.
Why I think they’re right about the problem#
The project page lists four things wrong with how we plan with agents today, and I nodded at all of them.
Planning chat isn’t interactive. You can’t point at paragraph three of the plan and say “not this bit”. The whole thing is a single-player experience; every tool on the market assumes one person talking to one model. Nobody owns the decisions, so there’s no record of who said yes to what. And plans are walls of text when half of them would be better as a diagram.
The one that stings is decision ownership. In my transcript story above, the decision existed, I’d made it myself, it was just buried in a chat log with a few friendly replies stacked on top of it. Chopin’s answer is to pull decisions out of the prose entirely. When the agent, which they call Planner, hits a choice the code can’t settle, it raises a question card. The team answers it and that answer is stored separately from the document text, so a later rewrite can’t quietly change what was agreed. The README puts it as the Planner “reads the selected repository, proposes changes, and asks the team when the code cannot settle a choice.”
The other design choice I like is that the Planner is read-only. It can read the repo and its pull requests through a bounded set of tools, and that’s it. It can’t write to GitHub, edit a checkout or implement anything. Compare that with the Copilot coding agent, Agent Merge and the Copilot automations announced at Universe, which are all about executing work. Chopin is the half of the loop that happens before anything executes, which is the half I’ve been missing.
How it hangs together#
From the architecture doc, Chopin is one Bun application, one browser client and one PostgreSQL database. The single process serves the web client, the HTTP API, a WebSocket for live editing and an MCP endpoint, all on one origin. The editor is Lexical with Yjs doing the live sync, and the stored format is a restricted MDX dialect, so the plan is a real document you can diff rather than a chat log.
The pieces you’d actually touch, as far as I can tell from the docs:
- Documents and channels. Each document is tied to one repo. Pull access lets you read, push or admin access lets you create, edit and invoke the Planner.
- The Planner. Mention
@chopinin the channel chat. It reads the plan, proposes edits, and raises decision cards when it needs a human to choose. - Research. Type
/researchin a document and a worker goes off, does web research, and publishes the report as a child document. - Comments. Threads anywhere in the document, resolvable, and a comment addressed to the Planner gets a reply.
- The implementation lifecycle. A plan’s task graph moves from draft to approved to locked. Once locked, a local coding agent claims tasks over MCP, opens one pull request per task and reports back. If scope changes mid-run it can request a revision, which unlocks the graph and sends it back to planning.
That last bullet is the bit I want to try most, and it’s also where the docs are most honest about the gaps. The architecture doc says there’s currently no production UI for a person to approve a draft task graph. So expect the hand-off half of the loop to be rough.
The Copilot CLI angle#
This is what makes it more than a curiosity for me. Chopin exposes a bearer-authenticated MCP endpoint, and the local-agent doc covers Copilot CLI alongside Claude Code and Codex. Wiring it up looks like this, taken from the docs rather than from my own run, which I haven’t done yet:
export CHOPIN_URL="http://127.0.0.1:8787"
export GITHUB_TOKEN="$(gh auth token)"
copilot mcp add --transport http chopin "${CHOPIN_URL%/}/mcp" \
--header 'Authorization: Bearer ${GITHUB_TOKEN}'The single quotes around the header matter; they keep the token reference unexpanded so it isn’t written into the config file. The doc’s own smoke test is to ask the CLI to use the Chopin list_documents tool to list the documents for the repository. From there the tools are read_document, create_document and update_document for authoring a plan from a CLI conversation, invoke_planner to kick the hosted agent from the terminal, and the lifecycle set: start_implementation, start_task, report_pr, complete_task, report_verification and request_revision.
The demo I have in my head is: plan in the browser with a colleague, answer the decision cards, approve, then in Copilot CLI run start_implementation and watch it open one PR per task. The repo even ships two skills that script this for an agent, one for creating Chopin plans and one for implementing them, with the rule “Create exactly one pull request per task”. Both are marked experimental. I’m going to find out how far that demo gets before something falls over, and I’ll write that up separately.
What you need to run it#
No public instance, so it’s self-hosting or nothing. The list from the README and the self-hosting guide: Bun (the two docs name different versions, so take the newer one), Docker with Compose for PostgreSQL, a GitHub App you create for this deployment with callback URLs on 127.0.0.1:8787, a GitHub account with push access to a test repo, and an active Copilot entitlement, because the default Planner harness sits on top of the Copilot SDK.
The run itself is short:
git clone https://github.com/githubnext/chopin && cd chopin
bun install
cp .env.example .env
openssl rand -hex 32
bun run db:up
bun run migrate
bun run devThe random hex goes into .env as the session encryption key alongside the GitHub App client id and secret. Then open http://127.0.0.1:8787, sign in, install the App on a test repo, create a channel and type @chopin. AGENT=off turns the Planner off if you only want to poke at the editor and the MCP side.
Caveats#
This is experimental research software and the README says so plainly: expect incomplete workflows, operational limits and breaking changes. It’s GitHub.com only; GitHub Enterprise Server endpoints aren’t configurable, so GHES shops can only evaluate it against a github.com test org.
The access model is worth reading before you point it at anything real. Two environment variables decide who may sign in at all, and if both are empty every verified GitHub user is admitted, so set them. Repo access then comes from where the GitHub App is installed, and the App only asks for read-only permissions, which is reassuring.
The Planner runs on the invoking user’s Copilot entitlement, and document and chat context is sent to Copilot during a turn. Whoever first invokes the Planner in a channel supplies the token for it, and the README says model access is billed to that first eligible user until their session ends or the server restarts. If your organisation has Copilot content exclusion or policy settings, this is the line to think about.
Operationally it’s one process, one database, one exact HTTPS origin and a single writer lease. No horizontal scaling, and a restart signs everyone out. Fine for a pilot, not for anything with an SLA.
There’s also a chopin CLI with an install script referenced in the README. The pull request that added it was merged in October but I couldn’t find a published release when I looked, so I’d treat the one-liner install as something to check rather than rely on.
Final thoughts#
If you’ve got a Copilot entitlement, Docker, and a spare test repo, clone it and spend an evening on it. Don’t try to use it for real work, the authors have told you not to. Create one plan, invite a friend from the team, mention @chopin, and see what happens when the Planner raises a decision card and you each pick a different answer. That single interaction is the whole bet, and it’s the thing I want to see for myself before the github.com team ships their version of collaborative planning documents. If you get there before me, I’d love to hear how it went.
