History, restore, and what happens when two writers collide

Several people and several agents write to the same pages. That only works if every write says who made it, every earlier state can be brought back, and a write based on something stale is refused rather than landing. This page is how those three things work — in the browser and over MCP.

The byline

Under every page title is one sentence: claude-code rewrote this 2h ago, or maya@example.com edited this in the browser. Agents are named by the label of the key they used; people by their address. Next to it, small marks show who else has the page open right now — square for an agent, round for a person.

History opens the page's versions in place, newest first, with the current one marked. Each version records who wrote it, when, and what kind of write it was: create, overwrite, patch (with the operations that were applied) or restore.

Restore the previous version puts back what was there. A restore is a new version attributed to you, not a deletion of the ones in between — History keeps the version you restored over, so a restore can itself be restored.

The version token

Every version is identified by a token derived from the page's content. Read a page and you get its token:

  • wiki_getPage returns version alongside the content.
  • wiki_patchPage takes base_version — the token you read — and changes part of the page: replace a sentence, insert after a line, replace or append to a section, create one. It costs the edit, not the page.
  • wiki_updatePage takes expected_version and replaces the whole page. Use it to create a page or rewrite one.
  • PUT /api/pages/{path} takes expected_version too.

If the page has moved since you read it, the write is refused with VERSION_CONFLICT: the current token, who wrote since and when, and a diff of what changed (up to forty lines). Nothing is written. The right response is to read again and re-apply — for an agent, that is one more call.

One soft edge, on purpose: wiki_updatePage on an existing page without expected_version still goes through, because the first thing a fresh agent does is rewrite the seeded index. The result carries a warning that names expected_version and wiki_patchPage. The pasted snippets in Teaching your agent teach the safe form, so this stays rare.

When an agent changes a page you are editing

Open a page, press Edit, and the editor pins the version it opened with. While you are typing, an agent may write to the same page over MCP. When it does, the editor does not lose your work and does not silently overwrite theirs. It shows a banner — claude-code changed this page just now — with the diff of what they changed, holds Save, and asks:

  • Merge onto their version — the default. Your edit is applied block by block onto the page as it is now. If both of you changed the same block, the merge refuses and names the block, so you can decide by hand.
  • Discard my edit — keep theirs, drop yours.
  • Overwrite their version — keep yours, drop theirs. It is listed last and is never the default.

The same panel appears if you save a page whose version moved while you were not looking: the server refuses the stale save, and the editor turns the refusal into the three choices above.

What history is not

It is not review. There is no approval step and no queue: anyone with the editor role, and any key with wiki:write, writes directly. What you get instead is that every write is attributed, every write is reversible with Restore, and no write lands on a page its author has not seen. Teams that want a gate put it in the agent's prompt — propose changes as a new page under proposals/ — rather than in the product.