Launching today
OpenMarkdown
A markdown editor you and your agent co-edit
167 followers
A markdown editor you and your agent co-edit
167 followers
A fast, light markdown editor that opens any `.md` file instantly. Your agent reads, writes, and co-edits the same file you're in — through a CLI, an agent plugin, and MCP. Local-first: no account, no telemetry, your files never leave your disk.
Interesting call to make it "co-edit" instead of AI-suggest. How do you handle simultaneous
edits when both you and the agent are typing in the same block — CRDT-style merge or last-write-wins?
OpenMarkdown
@chetan00118 Great question!
OpenMarkdown's MCP supports section-level writing. There are two situations then.
1. When the agent writes to a different section than the one you're in, its edit lands as a scoped transaction in your live buffer. No reload, no lock.
2. When you're both in the same section, it's optimistic concurrency: every agent write carries a hash of what it read, and if you've touched that section since, the write is rejected (not merged, not overwritten) — your edits are untouched and the agent re-reads and retries. So on a real collision the agent yields 😊
A compare-and-swap per section is lighter, and it keeps the plain .md as the source of truth.
We are still looking for the best way to handle the concurrency for the best user experience and best performance. Let me know if you have any suggestions or other questions~
(ps: a new section for step-by-step interactive agent demo on the landing page should be sync'ed within the next 30 mins; please feel free to give it a try~)
@xueyanzhang Optimistic concurrency with per-section hash-CAS is a nice compromise — keeps .md as source of truth while letting agents yield gracefully on real collisions. That's more elegant than CRDT overhead for a doc format. I'll try the interactive demo when it's live. Thanks for the deep dive 🙏
OpenMarkdown
@chetan00118 Exactly — "yield gracefully on real collisions" is the phrasing I'm stealing 😄
Good news, no waiting — it's live now.
Thanks for the sharp questions! It means a lot.
the hash-CAS handles human vs one agent well, but what about two agents on the same file at once, say Claude Code in one terminal and a separate MCP client in another? does that logic run agent-to-agent too, or can both read the same stale hash and clobber each other's section?
OpenMarkdown
@sabber_ahamed Yes — agent-to-agent runs on the exact same hash-CAS. The check is on the section's content, not on who's writing, so a second agent (Claude Code in one terminal, an MCP client in another) is treated no differently from a human.
Concretely:
- Different sections → both writes land, no conflict.
- Same section → writes go through the one running app one at a time, so the second one's baseHash is now stale; its replace is rejected and it re-reads. Two agents can't both read a stale hash and silently clobber — the loser gets a CONFLICT and retries, same as human + agent.
That's a guarantee for writes going through "write_section" (they carry the hash). If an agent bypasses the tools and just rewrites the file with plain Write/Edit, it's outside the check — two agents both doing raw file writes fall back to whoever-hits-disk-last.
We are still exploring to push conflict below the section, so two agents editing different sub-parts of the same section don't trip a conflict at all. Today the unit is the section. Please stay tuned~
local-first with zero telemetry is the right call for anything touching real files - same constraint we build to on-device, nothing leaves the device. does co-edit rely on file watchers or does the agent poll for changes you make mid-edit?
OpenMarkdown
@sabber_ahamed Appreciate that — "nothing leaves the device" is exactly the line, good to hear it's the same bar you hold on-device.
Your agent through the MCP server — the wait_for_change tool blocks until the file actually changes and gets pushed a wake-up.
For your "mid-edit" case specifically: your keystrokes reach disk via autosave, and the wake is tail-edge debounced — it fires once you pause, not on every character. The agent wakes to a settled file, not a half-typed line.
Easiest way to feel it is the interactive guidebook — paste this to your agent and it sets everything up:
(just enable the openmd CLI in Settings first). Let me know how it feels~
curious if you plan to keep remote review out of scope. the editor/agent loop looks clean, but once i send the doc to someone who doesn't have OpenMarkdown, their exact paragraph-level correction still comes back in Slack and i have to carry it into the agent by hand. is there a hook in the CLI/MCP for feedback from a shared copy, or do you see that as a separate layer?
OpenMarkdown
@eason_zhou You found the real edge — inside the machine it's clean, and the second the doc leaves for someone without OpenMarkdown, you then become the courier.
Start from a principle: the file on disk stays plain .md, no extra metadata. That was a founding line for us — so "review" doesn't get to live in the file as comment threads or suggestion-mode cruft.
Currently we can use agent as the glue. Agent is used to get the reviewer's note from Slack, and it writes the diff back as a section-scoped edit — same concurrency-safe path as everything else. Nothing uploads, the file never leaves your machine; the reviewer's words just land as a clean edit. You stop being the courier — the agent is.
The harder frontier is when the file itself lives on a shared drive and two people touch it at once. Guarding that concurrency — git/patch-style, staying file-native rather than bolting on a server — is something we're actively chewing on. Not solved, genuinely open.
Curious about your situation: When a correction comes home, is it usually a full edited .md copy, or conversational ("para 3 reads too harsh")? 😊
the co-edit mode is the part I want to know more about, specifically the collision case. if I'm mid-sentence typing in one section while the agent is writing to a different part of the same file at the same moment, does it just interleave the writes cleanly, or is there some kind of lock/turn-taking so we're not fighting over the same save
OpenMarkdown
@galdayan Great question 😊 The editor buffer is the file.
[case 1] when the agent writes to a different section than the one you're in, its edit lands as a scoped transaction in your live buffer: your cursor and unsaved text don't move, no reload.
[case 2] if you both land in the same section at once, the agent's write carries a hash of what it read — if you've changed the context before the agent, that write is rejected and the agent re-reads. So you're never fighting over the same save, and your edit wins.
It's live to try now — step-by-step interactive agent demo on the landing page (install by pasting a prompt into your agent). Let me know how it feels~
@xueyanzhang the hash-check on write is the neat part - that's a real optimistic-concurrency mechanism, not just "last write wins." going to try the landing page demo to see how it feels in practice, especially the same-section case
OpenMarkdown
@galdayan Exactly — that's the part I care about most: on a real collision your edit wins and the agent yields. 🙌
Easiest way to try it: after installing, paste this to your agent →
(ps: enable the openmd CLI in Settings → CLI first 😊)
a co-editing markdown tool is a really clean idea, I've had too many docs where an agent's edit and mine collide and one of us silently overwrites the other. does it show live cursors/diffs while the agent is writing, or do you only see the change after it commits its edit?
OpenMarkdown
@omri_ben_shoham1 Thank you for your interest 😄 (and no — neither of you silently overwrites the other; a collision just makes the agent re-read and retry.)
Two honest UI caveats for now: no live cursor showing where the agent is (no Google-Docs presence marker), and no red/green diff yet — you see the result appear live, in place, not a before/after.
A diff view is the piece a few folks here have asked for, and your question splits it neatly into two modes I'm weighing:
- live diff — the agent writes, then leave a notification on the banner. click to jump to the newly added section (possibly highlighted in a box); and
- review diff — it commits, then you see a before/after to accept or reject (curosr like).
They could co-exist, if they doesn't affect the response speed too much. Which one do you find more useful?
Keeping the Markdown file as the source of truth while allowing section-scoped agent edits is a strong design choice. How are you thinking about provenance—showing which passages came from the user versus the agent after several rounds of co-editing?
OpenMarkdown
@amir_mehrabi Thank you! Keeping authorship distinguishable across several rounds is a great question — and since it's local-first, the .md file is the ground truth, so whatever we do has to live in the file.
Rather than one universal "color the agent's text" layer, I lean toward letting the scenario decide:
- Pure formatting (say, CSV → table): I only care that it's correct — edits happen in place, no provenance needed. (Whether in-place edits should also offer an in-editor review/marker came up in another thread — at least the user should get the choice.)
- Writing a report, where the agent pulls a section in from a repo: a lightweight in-text record fits — e.g. "- [x] @agent · completed 2026-07-18". A timestamp right there in the file is welcome/acceptable.
- A shared task board: you can carve out a dedicated agent-response area in the doc itself, so provenance becomes structural (like the screenshot).
Curious — what scenarios do you reach for most? Would love to figure out together how to make it better~