OpenMarkdown
A markdown editor you and your agent co-edit
258 followers
A markdown editor you and your agent co-edit
258 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.
Free
Launch Team / Built With
Render: Get up to $100K in startup creditsThe fastest way to launch and scale your startup in the cloud
Promoted
Local-first with agent co-editing through MCP is a smart wedge — most agent-editor integrations force you into someone's cloud. We live in markdown files all day (our agents keep their working memory as .md docs), so an editor where the human and the agent are first-class co-editors of the same file is genuinely useful. How do you handle conflicts when the agent writes while I have unsaved edits in the buffer?
@nitish_garg4 Thank you for the great question. OpenMarkdown provides special "write tools" to the coding agent and thus it allows section-level edit. There will not be "lost of unsaved work" or "change of user's cursor focus".
When editing the same section, the agent keeps an hash of the orig content, and will yield when there is a conflict with user's edit. The agent will fullfill the request again, based on the new contents.
I totally agree the .md is becoming the first-citizen, given all the design.md, memory.md and skill.md. Soon, we will provide customized visualization / edit experience to these file types. E.g., dedicate SKILL editing interface.
Co-editing with an agent in the same document (rather than a separate chat panel) is a genuinely different interaction model — most AI writing tools still keep you and the model in separate spaces. How are you handling conflict resolution when both a human and the agent want to edit the same section at roughly the same time? Curious if there's a locking mechanism or something more like real-time merge.
@abhineetarora Neither a lock nor a live merge — a third path, and it rides on the same section-scoping. 🙂
The agent doesn't edit "the file," it edits a section. read_section / write_section are scoped to a heading, so most of the time you two aren't even in the same block — nothing to resolve.
When you do land on the same section, the write bounces as a CONFLICT, the agent gets your current text + a fresh hash in the same round-trip, and re-runs its edit against what you just typed. Optimistic concurrency, closer to git than to a lock.
@xueyanzhang That's a clean solution — scoping to sections mostly avoids the problem entirely, and optimistic concurrency with a hash-based re-run for actual collisions is a much better fit for this than a lock would be (locks would make the "co-editing" feel more like turn-taking than genuine collaboration). The git-like framing makes sense too — conflict resolution as a rare, explicit event rather than something constantly negotiated in the background. Nice architecture — good luck with the launch!
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
@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
@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 😊)
@xueyanzhang Appreciate the pointer - I'll grab a few minutes to actually run through the landing page demo myself rather than just taking your word for the collision behavior. Nice touch enabling the CLI toggle separately, keeps the default install lighter for people who don't need it yet.
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?
@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?
@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~
Curious why a new editor and not a plugin for VS Code or Obsidian where people already keep their md files? Not asking to be rude, genuinely want to know what the standalone app gets you that a plugin can't.
@arya012 Great question, thanks for asking it directly.
Honest answer: for reading and writing markdown, VS Code's native preview is already great — I use it daily. OpenMarkdown isn't trying to replace it, or Obsidian (which I still use for project management, its vault model is great for that).
What a standalone app gets you is two things a plugin can't:
Speed as a scratchpad. Built on Tauri v2 (Rust), it opens instantly on any .md file — including the random files my code agents leave lying around, which a vault-based tool won't show me.
A shared whiteboard between you and your agent. This is the real reason it's standalone. The file is shared memory; the app is just the renderer. Because it's not trapped inside one host's plugin sandbox, the built-in MCP lets an agent work in the same document you're looking at — it can react to the section you highlighted, search/open/highlight across your notes, and co-edit with you live.
A plugin lives inside one tool's world. A file-based app is neutral ground both you and any agent can meet on.
Curious what sets this apart from collaborating with an agent on a .md file in something like VSCode?
@inferhaven Thanks for your question 😊 You can absolutely point an agent at a .md in VS Code.
First, OpenMarkdown is a fast markdown surface, not an IDE.
It renders, opens instantly or a quick peek-and-fix, and stays out of the way.
The co-edit path is built for the shared-file case, section-scoped, with your cursor preserved and per-section conflict checks.
It's not a strict replacement. I still live in VS code for code editing. However I do see trend that coding agent is getting better than ever; I use less VS code recently.
OpenMarkdown is for when you want the quick peek into markdown view/edit.
Easiest way to feel the difference: the interactive agent demo on the landing page, install by pasting a prompt into your agent~