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.
OpenMarkdown
OpenMarkdown
@agent Please feel free to try our agent guidebook — an interactive demo where OpenMarkdown and your agent walk you through it together, including the live co-edit. Paste the prompt into your agent to start (just enable the openmd CLI in Settings first), and let us know if anything doesn't go smoothly~
Co-edit mode writing into the same .md file I'm actively typing in is the part I'd stress-test first — most 'agent + editor' tools use a separate pane precisely to dodge that. When the agent and I write to the same section at once, how does it reconcile: file-watch reload with last-write-wins, or an actual diff merge so my in-flight edits aren't clobbered? And since you dropped caching for RAM on Tauri 2, does peek-open stay instant on large multi-MB markdown, or is that where the no-cache tradeoff shows?
OpenMarkdown
@hi_i_am_mimo You're stress-testing exactly the right thing 😊
On reconciliation: it's not a file-watch reload with last-write-wins. Agent writes are section-scoped and land as a transaction in your live buffer. If 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 in-flight edits are never clobbered; the agent re-reads and retries. The plain .md stays the source of truth.
On speed: peek-open stays instant for everyday files — dropping the cache is about not hogging RAM (personally, I'd be frustrated to see a "simple editor" eat a huge amount of it). In my own daily use I haven't hit response-time issues with large .md files.
Would love your stress-test notes~
The concurrency answers here all assume the agent sends a small edit, but in practice most coding agents rewrite the whole file even for a one-line change. When an agent edited a CLAUDE.md I was mid-sentence in, the pain wasn't a merge conflict, it was losing my cursor position and undo history to a wholesale rewrite that section-level hash-CAS still treats as one big dirty region. Do you constrain the agent to patch anchored ranges, or accept a full write and reconstruct the minimal diff yourself?
OpenMarkdown
@dipankar_sarkar Sharpest version of the question — thank you.
Short answer: both, and which one kicks in depends on whether the agent goes through our MCP tools or just writes the file itself.
- Through our MCP (write_section): the agent is constrained to an anchored range — it patches a section by heading, never the whole document (there's no full-document replace).
- Writing the file directly (the case you hit — most agents rewrite the whole thing with their bash tool): we diff the new file against your live buffer and apply only the minimal change, as a remote edit, so your cursor maps through it instead of resetting.
Honest limit: if the rewrite also reflows the whole file, the "minimal" diff stops being minimal — and keeping the agent's edit out of your undo stack is still on my list (still looking for the best design for the best user experience).
You've named the real open gap. Would love your take on anchoring that survives a reflow~
The write_section path is the clean answer, but the direct-file-write path is the one I hit most, since Claude Code and Cursor both grab their own Write/Edit before any project MCP. On that path, when the agent rewrites the whole file, does openmd diff it back down to section granularity so my undo history and cursor survive, or does the buffer reload as one big edit? That reload is what actually loses my place mid-sentence.
OpenMarkdown
@dipankar_sarkar Great question!
It diffs, it doesn't reload. The watcher takes the incoming file, computes the minimal diff against your live buffer, and applies just the changed ranges as one precise edit — so a whole-file rewrite that only really touched one section collapses back down to that section. Your cursor, scroll, and undo history ride along on everything that didn't change.
Honest caveat: it's diff-granularity, not literally "sections" — if the edit lands right where your caret sits, that spot does move. But you never eat a full-buffer reload mid-sentence.~
The co-editing angle is the interesting part. The section-scoped hash-CAS approach makes sense for simple edits, but OT and CRDTs usually struggle with the same edge case: an agent producing a large structural rewrite while a user is mid-sentence in that region. Does it fall back to last-writer-wins, or is there a way to express intent at finer granularity than section level?
OpenMarkdown
@anand_thakkar1 Thank you for the insightful question~
Not last-writer-wins — that's the line I most wanted to avoid. On a stale write (section-scoped) the agent's edit is rejected (the section's hash no longer matches what it read) and it re-reads; your in-flight text is never overwritten. So even in your edge case — a big rewrite while you're mid-sentence in that region — the agent yields, not you.
On finer granularity, we are still exploring the right approach. The applied edit is minimal-diffed, so it's small when the real change is small — but the unit of conflict is still the section, not a sub-range. Block-level scoping is likely the right next step for finer control — curious how you'd approach it. Would love your take~
The local-first angle is exactly what pulled me in, and the co-editing through MCP feels genuinely useful. One thing that would make this a daily driver for me: a quick toggle to preview the markdown in a side pane with synced scrolling, so I can spot broken links or formatting drift while my agent is still writing.
OpenMarkdown
@berkantozg31053 So glad the local-first + MCP co-edit clicked for you 😊
This might already cover it: OpenMarkdown doesn't do a split source / preview pane — it renders live, inline, in the same pane as you (or your agent) type. So formatting drift shows up the moment it's written, with no second pane to keep scroll-synced. One button also cycles to reading mode (the clean rendered page) and source mode.
Personally, live preview has been the best experience for me — each line renders in place as I type. And when I do need the raw markup, source mode renders it with syntax colors (easier on my eyes) instead of a second pane. I kept it single to stay light.
Genuinely curious what a dual pane would give you over live preview — if it's a real gap, I'd love to understand the workflow before deciding.
(I attached two screenshot of the app under "live preview" and "source" mode for reference~
OpenMarkdown
@berkantozg31053
Congrats on the launch! I like the idea of keeping the editor lightweight while letting users bring whichever agent already understands their project.
The shared-file approach feels much more natural than copying content between an editor and a separate AI pane. I’m curious how you prevent collisions when the user and agent edit the same section at once.
Looking forward to trying it.
OpenMarkdown
@mingtian_zhang Thank you, that means a lot 😊
On the same-section case: agent writes are section-scoped and carry a hash of what the agent read. Before applying, `openmd` check you haven't changed that section under it — if you have, the write is rejected (not merged, not overwritten) and the agent re-reads and retries, so your edits are never clobbered. Different sections just interleave cleanly.
There's a step-by-step interactive agent demo on the landing page, and you can install by pasting a prompt into your agent: https://openmarkdown.dev Would love to hear how it feels~