I asked an AI agent to cross-post a 7,000-character article from dev.to to Hashnode.

The Submit click succeeded. Hashnode returned a draft URL. I clicked through.

The draft had 446 characters: the first paragraph, then 41 empty paragraphs, then the last paragraph.

This is a postmortem of how I got there, why my first three diagnoses were wrong, and what fixed it. If you're shipping any kind of browser automation that touches modern rich-text editors, this one is worth the read.

The setup

Safari MCP is the macOS-native browser automation tool I maintain. One of the things it has to do is fill rich-text editors — Quill, ProseMirror, Lexical, the React-controlled stuff Featured.com uses, and a dozen variations.

For the cross-posting flow specifically, the agent does this:

1. Opens the Hashnode "new draft" page in my real Safari (already signed in).
2. Drops a 7,000-character markdown body into the editor.
3. Clicks Publish.

That's it. It worked for years on dev.to, Medium, X, LinkedIn (after their 2026 Quill migration), Featured.com. Hashnode was supposed to be the easy one — they sell themselves as "developer-friendly".

The symptom

After Submit, the draft saved with this structure:

<p>First paragraph (intact, ~280 chars).</p>
<p></p>
<p></p>
<p></p>
... 41 empty <p> tags ...
<p></p>
<p>Last paragraph (intact, ~166 chars).</p>

Total saved: 446 chars. Total sent: 6,808 chars. The middle 94% was silently dropped.

The agent had no error. The fill call returned successfully. The Submit click returned successfully. Hashnode's own draft view showed the broken structure as if it were intentional.

First diagnosis (wrong): paste race condition

My first guess was a paste-event timing issue. I'd recently fixed a similar bug on X.com where the synthetic ClipboardEvent('paste') was racing with their React useEffect cycle. The fix had been an explicit execCommand('delete') before the paste.

I tried the same thing here. No change.

I added a safari_verify_state call between fill and submit. The verifier confirmed the editor's .textContent matched what I sent — at the moment I checked. But by the time Submit fired ~100ms later, the editor state had reverted.

So whatever was eating the middle paragraphs, it was doing it after the fill returned. The agent's "success" signal was lying.

Second diagnosis (wrong): markdown auto-conversion

Hashnode's editor does auto-format certain characters at the start of a line:

• > → blockquote
• ** → bold marker
• [ → link helper
• # → heading

I noticed the body had several paragraphs starting with these characters. So I theorized: the editor was rejecting paragraphs whose first characters tripped auto-format prompts, leaving them empty until the user manually accepted.

Fix: I escaped the leading characters with a zero-width space. Re-ran. Result: still 446 chars saved.

So that wasn't it either.

Third diagnosis (wrong): React reconciliation order

Hashnode's editor wraps ProseMirror in a React component. I suspected that the multiple beforeinput events I was dispatching were getting batched and only the first + last applied.

I switched from beforeinput to composing text events with intermediate setTimeout(0) calls to give React's render cycle a chance to flush.

Still 446 chars.

At this point I was four hours in and getting irrationally angry at a contenteditable div.

The real bug

I read the Safari MCP fill pipeline. For ProseMirror editors, it does this:

1. Walk the DOM looking for .pmViewDesc (ProseMirror's view marker).
2. If found, call view.dispatch(tr.replaceWith(...)) — the canonical way.
3. If not found, walk React Fiber for memoizedProps.view.
4. If still not found, fall through to char-by-char beforeinput + execCommand('insertText') per line.

Path 4 is the fallback for editors that don't expose ProseMirror's internals. It's worked everywhere I'd tested it. Including Hashnode in earlier dev.

But it has one assumption baked in: that the editor will accept the text it's told to insert. If the editor rejects an insert silently — for any reason — the fill pipeline never finds out. The function returns success. The DOM has empty paragraphs.

Hashnode's ProseMirror configuration has an "input rules" plugin that runs on every paragraph start. The plugin's job is to handle markdown shortcuts. But its implementation aborts the insert if the matched text doesn't form a valid command — and just doesn't insert anything.

So > blockquote text doesn't become a blockquote. It also doesn't become a regular paragraph. It becomes nothing.

The fill pipeline is char-by-char per line. It walks down, fires beforeinput, fires execCommand. The input rule fires on each >, kills the line silently. Pipeline moves to next line. Same thing.

Only paragraphs whose first character doesn't trip a rule survive. In my article, that was paragraph 1 and the final paragraph.

The fix

The fix is straightforward once you see it:

// After char-by-char fill, verify what actually landed.
const actual = editor.textContent.length;
const expected = value.length;

if (actual < expected * 0.6) {
  // More than 40% missing. The editor ate it.
  // Clear via DOM replacement, then re-fill via insertHTML with paragraph-wrapped HTML.
  while (editor.firstChild) editor.removeChild(editor.firstChild);
  const html = value
    .split('\n\n')
    .map(p => `<p>${escapeHtml(p)}</p>`)
    .join('');
  document.execCommand('insertHTML', false, html);
  return `Filled CE (ProseMirror insertHTML fallback, ${editor.textContent.length}/${expected})`;
}

insertHTML bypasses the input-rules plugin because the rules only fire on character-level input events. A bulk HTML insert is treated as a paste and goes through a different code path — one that doesn't run the markdown-shortcut interceptor.

Important: the values going through escapeHtml and insertHTML here come from the agent's own controlled context — text the agent itself is trying to place into a logged-in editor in the user's own browser session. This isn't a server rendering untrusted user input, so the escape step is purely to preserve the literal characters, not to harden against an attacker.

Verify-after-fill is the part that took me too long to add. Trust the framework to tell you what happened, not the call that just returned.

This shipped in v2.10.4 of Safari MCP.

The lesson

The deeper issue isn't ProseMirror. It's the assumption that a successful tool call means the action succeeded.

Browser automation has a recurring failure mode: the framework keeps its own state separately from the DOM, and the framework's state is what gets submitted on form post. Your synthetic events change one or the other, sometimes both, sometimes neither. The DOM looks right. The submit ships the wrong thing.

I added a tool called safari_verify_state in v2.10.0 specifically for this. It checks framework state (ProseMirror view, Lexical editor state, React _valueTracker desync, Closure component values) and returns whether the framework agrees with the DOM. The Hashnode ProseMirror case is now a built-in check.

If you're building any agent that touches a serious editor — Quill, ProseMirror, Lexical, Slate, Tiptap — assume the fill happened, then verify what landed before you click Submit. The 5 ms it takes is the cheapest insurance you'll buy this year.

Postscript

I cross-posted this article using the fixed code path. It saved as 41 intact paragraphs.

The agent didn't notice anything was different. That's the point.

Safari MCP is open source (MIT) and runs on macOS. It's used by Claude Code, Cursor, and other MCP clients to drive a real, logged-in Safari instead of spinning up a headless Chromium.