[zurfyx]

Description

Text nodes that Lexical keeps apart from an equal neighbour (a tab, text in token or segmented mode, and every TextNode subclass such as a hashtag or a code highlight token) are stored as runs with a segment key, opened and closed by format items their writer adds. This PR fixes two cases where a tab was lost, and one where token or segmented text lost its mode:

• A tab written right after a collaborator's tab, which the collaborator undoes. The new tab landed inside the other tab's run and wrote only its segment key, reading its type from the other tab's opening write. The collaborator's undo deleted that write, and the tab was read as a "\t" in the text before it, on every client. Now a tab written inside another client's tab run, whose own write opened the type, writes its own type item. The write is recognized whatever its size (a tab's opening write holds one item per comment id on it). Nothing else is owned: a link or format of the text around would come back where a collaborator removed it at the same time, and other types and modes follow the run they are written in, where a concurrent change of the line must reach them (a code line made a paragraph turns its highlighter's tokens into plain text). For hashtags, code highlight tokens and token or segmented text in that placement, see Bug: [lexical-y] A hashtag, code highlight token or token/segmented text written right after a collaborator's node of the same kind becomes plain text when the collaborator undoes theirs #9586. A tab written after a collaborator's second consecutive Tab press is not covered (the type then comes from their first press's write): see Bug: [lexical-y] A tab written after a collaborator's second consecutive Tab press becomes a "\t" in the text before it when the collaborator undoes both presses #9604.
• Two clients' tab characters under one tab opener (left in stored documents by the case above through undo and redo) were read as one tab node: one tab was not shown, and the binding's self-check reported the line (text "code\t\txx" != "code\txx"). Each tab character is now read as a tab node of its own, and the reader keeps every node of a segment, so both keep their keys across remote edits.
• Token or segmented text written right before a collaborator's node of the same kind could land inside that node's run: the cursor stepped past the items of the node's opening write other than its type and segment keys (its mode), and the collaborator's undo then took the mode from the new text. The cursor no longer steps past those items; it still steps over the write's wrapper items, so content written inside a link right before a node that opened it shares the link and loses it with the rest.

A tab written after a tab of the same client owns nothing (the client's own undo removes its later write first), so consecutive Tab presses store as many format items as on main.

Reported downstream (a collaborative notes app's randomized test with undo).

Changeset

.changeset/lexical-y-own-segment-run.md (@lexical/y patch, [fix] with Verify:).

Test plan

packages/lexical-y/src/__tests__/unit/TabLeak.test.ts:

• "a node kept apart written next to another client's": B adds a node inside plain text (a run of its own), A adds one right after or before it, B undoes or removes its node; tab, token, segmented, bold token and hashtag in a paragraph, tab and code highlight token in a code block, both client orders. The 10 "after + undo" cases for kinds other than a tab are test.fails naming Bug: [lexical-y] A hashtag, code highlight token or token/segmented text written right after a collaborator's node of the same kind becomes plain text when the collaborator undoes theirs #9586 (with [lexical-y] Bug Fix: Keep the run ends of text an undo removes, and end a value an undo ends past other writes' run ends #9561, the token, segmented and bold-token ones pass; flip them when both have landed).
• "tab characters under one tab opener": a second tab character written inside a tab's run reads as two tab nodes, which keep their keys across a remote edit.
• "a node kept apart written where a peer removes the link or format around it": a tab, hashtag or token typed inside a link while a peer removes the link, a bold one typed into bold text while a peer unbolds it, and a tab right after another client's tab inside a link while a third client removes the link.
• "content written inside a link right before a node that opened it": text before a hashtag that opened a link, then its author undoes or a collaborator unlinks; a tab before a tab that opened a link, then a collaborator unlinks.
• "a tab written after a tab whose opening write holds many items": 1, 16, 64 and 128 comment ids on the first tab.

pnpm exec vitest run --project unit packages/lexical-y/src/__tests__/unit/TabLeak.test.ts

Before

On main (e28f4dd), the tab, token, segmented, two-tab, link and many-ids cases fail (each commit's message lists its own before and after output).

After

 Test Files  1 passed (1)
      Tests  107 passed | 10 expected fail (117)

pnpm exec vitest run --project unit packages/lexical-y packages/lexical-code packages/lexical-hashtag packages/lexical-link packages/lexical-mark
      Tests  9361 passed | 56 expected fail | 5 skipped (9422)

The randomized notes-app test: 2000 of 2000 seeds pass. Fuzz.test.ts with
FUZZ_SEED_START=1 FUZZ_SEEDS=3000 and FUZZ_SEED_START=50000 FUZZ_SEEDS=2000: the same 8 seeds fail as on main, every other seed passes.
The recorded session of the previous commit: no self-check report; 150
sessions of that lane: the same counts of every flag kind as on main.
pnpm run ci-check passes. Eight Tab presses at the end of a line: 18 live
format items (18 on main, 26 on the previous commit).

Browsers were not exercised (headless and jsdom unit tests only).

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated
lexical	Ready	Preview	Oct 30, 2026 5:22pm UTC
lexical-playground	Ready	Preview	Oct 30, 2026 5:22pm UTC

[meta-code-review]

AI review status for this pull request.

Review status	Updated
🔄 In progress (for maintainers only)	Oct 30, 2026, 5:23 PM UTC

[pkg-pr-new]

lexical

npm i https://pkg.pr.new/lexical@9578

@lexical/a11y

npm i https://pkg.pr.new/@lexical/a11y@9578

@lexical/clipboard

npm i https://pkg.pr.new/@lexical/clipboard@9578

@lexical/code

npm i https://pkg.pr.new/@lexical/code@9578

@lexical/code-core

npm i https://pkg.pr.new/@lexical/code-core@9578

@lexical/code-prism

npm i https://pkg.pr.new/@lexical/code-prism@9578

@lexical/code-shiki

npm i https://pkg.pr.new/@lexical/code-shiki@9578

@lexical/compiler

npm i https://pkg.pr.new/@lexical/compiler@9578

@lexical/devtools-core

npm i https://pkg.pr.new/@lexical/devtools-core@9578

@lexical/dragon

npm i https://pkg.pr.new/@lexical/dragon@9578

@lexical/eslint-plugin

npm i https://pkg.pr.new/@lexical/eslint-plugin@9578

@lexical/extension

npm i https://pkg.pr.new/@lexical/extension@9578

@lexical/fast-check

npm i https://pkg.pr.new/@lexical/fast-check@9578

@lexical/file

npm i https://pkg.pr.new/@lexical/file@9578

@lexical/hashtag

npm i https://pkg.pr.new/@lexical/hashtag@9578

@lexical/headless

npm i https://pkg.pr.new/@lexical/headless@9578

@lexical/history

npm i https://pkg.pr.new/@lexical/history@9578

@lexical/html

npm i https://pkg.pr.new/@lexical/html@9578

@lexical/internal

npm i https://pkg.pr.new/@lexical/internal@9578

@lexical/link

npm i https://pkg.pr.new/@lexical/link@9578

@lexical/list

npm i https://pkg.pr.new/@lexical/list@9578

@lexical/mark

npm i https://pkg.pr.new/@lexical/mark@9578

@lexical/markdown

npm i https://pkg.pr.new/@lexical/markdown@9578

@lexical/mdast

npm i https://pkg.pr.new/@lexical/mdast@9578

@lexical/offset

npm i https://pkg.pr.new/@lexical/offset@9578

@lexical/overflow

npm i https://pkg.pr.new/@lexical/overflow@9578

@lexical/plain-text

npm i https://pkg.pr.new/@lexical/plain-text@9578

@lexical/react

npm i https://pkg.pr.new/@lexical/react@9578

@lexical/rich-text

npm i https://pkg.pr.new/@lexical/rich-text@9578

@lexical/selection

npm i https://pkg.pr.new/@lexical/selection@9578

@lexical/table

npm i https://pkg.pr.new/@lexical/table@9578

@lexical/tailwind

npm i https://pkg.pr.new/@lexical/tailwind@9578

@lexical/text

npm i https://pkg.pr.new/@lexical/text@9578

@lexical/utils

npm i https://pkg.pr.new/@lexical/utils@9578

@lexical/y

npm i https://pkg.pr.new/@lexical/y@9578

@lexical/yjs

npm i https://pkg.pr.new/@lexical/yjs@9578

commit: f953cf4

[meta-code-review]

Thanks for tracking this down. The undo case is real: against the base source the new TabLeak.test.ts fails exactly the 10 tests listed in the Test plan, and with this change they pass (a redo by B afterwards also comes back clean). A few things need attention before this can go in.

1. A concurrent link or format removal is reverted (please fix)

ownSegmentKeys (packages/lexical-y/src/internal/Cursor.ts:532-547) returns every key with a non-null value whenever the inserted content's segment differs from the cursor's, including when the cursor sits in plain text with no segment at all. insertFormats (lines 557-558) then writes an opener for each of those keys and records it in negated, so a restore of the surrounding run's value is written after the content. A tab typed inside a link is now stored as {w:link}{t:"tab"}{k}\t{w:link}{t:null}{k:null} (on main: {t:"tab"}{k}\t{t:null}{k:null}). A peer that removes the link (or bold) at the same time never sees those items, so every peer converges with the link back on the inserted node and on the text after it. With the existing harness:

test('a tab typed inside a link while a peer removes the link', async () => {
  const t = await setup(() =>
    $getRoot().append(
      $createParagraphNode().append(
        $createLinkNode('https://example.com').append($createTextNode('abcd')),
      ),
      $createParagraphNode().append($createTextNode('next line')),
    ),
  );
  t.offline();
  t.a.update(() => {
    const link = $block([0]).getFirstChild() as ElementNode;
    const [, right] = (link.getFirstChild() as TextNode).splitText(2);
    right.insertBefore($createTabNode());
  });
  t.b.update(() => {
    const link = $block([0]).getFirstChild() as ElementNode;
    for (const child of link.getChildren()) {
      link.insertBefore(child);
    }
    link.remove();
  });
  await t.sync();
  // main: paragraph("ab", tab, "cd"); this branch: paragraph("ab", link(tab, "cd"))
  for (const peer of t.peers) {
    expect(peer.read(() => $block([0]).getChildren().some($isLinkNode))).toBe(false);
  }
  await expectConverged(t.peers);
});

The same happens with a hashtag or token text instead of the tab, with a bold hashtag or bold token typed into bold text that a peer unbolds ("cd" comes back bold), and with A's tab right after B's tab inside a link. This is the situation the cursor's own invariants are written to prevent (the minimizeFormatChanges comment and rule 4 of format: a comment resolved while a peer typed came back). A narrower rule should keep your fix: own only the keys whose value at the cursor comes from the segment's own run (the items the segment author's write opened, for example this.sources entries from the same client and write as the k source, as oneFormatWrite checks), return null when the cursor has no segment, and never own an inherited wrapper key. Please add the link and bold cases as tests.

2. The token and segmented cases do not exercise the bug

In TabLeak.test.ts the token, segmented and bold token variants also pass without the fix: B's node is inserted right before the setup's token PP (lines 405 and 414), B's write steps over PP's p:mode opener (only t and k openers are protected, Cursor.ts:466-470), and A's node then depends on the setup writer's opener, which B's undo never removes. If B's token opens a run of its own instead (for example B splits "ab cd" and inserts its token after "ab", A adds one right after it, B undoes), main loses A's token and this branch keeps it. Using that setup would make the token and segmented claim in the description and changeset tested.

3. Changeset Verify: wording

.changeset/lexical-y-own-segment-run.md ends with "Documents written before this fix keep how they read", but with the reader change a stored line whose two tabs had collapsed into one now shows both. CONTRIBUTING.md asks a fix that changes observable behaviour to say what to verify, so please mention that case.

Minor

• With two "\t" under one opener the two tab nodes share a segment key, and takeText maps a segment to a single node (Read.ts:2372-2390), so each remote edit of that line recreates one of the tab nodes (the caret stays in place). Mapping a segment to a list of nodes would keep both keys.
• Owned items add stored format items (eight Tab presses in one line: 18 before, 26 after); the narrower rule above should shrink that as well.

[meta-code-review]

This owns every key with a non-null value, including inherited ones such as a link (w:link) or f:bold, and also when the cursor has no segment at all (plain text). insertFormats then records each in negated, so a restore of the surrounding run's value is written after the content. If a peer removes that link or bold concurrently, the restore brings it back over the inserted node and the text after it (a tab typed into linked abcd while a peer unlinks it ends as "ab" link(tab "cd") on every peer; on main the link is gone). Could ownership be limited to the keys the segment author's own write opened, with null when the cursor has no segment?

[zurfyx]

Fixed in 0f080d9 and narrowed again in 904c01c: content that starts a segment inside another segment's run now owns only a tab's type, and only when that segment's own write opened it; never a wrapper or a format, and nothing when the cursor has no segment. Your link case and the bold case are tests in TabLeak.test.ts ("a node kept apart written where a peer removes the link or format around it"), plus A's tab right after B's tab inside a link while C removes the link.

[meta-code-review]

For the token, segmented and bold token kinds these cases also pass without the fix: B's node lands right before the setup's token PP, B's write steps over PP's p:mode opener (only t/k openers are protected in minimizeFormatChanges), so A's node depends on the setup writer's opener, which B's undo never removes. Inserting B's token where it opens its own run (for example after "ab" in a plain "ab cd") makes these fail on main and pass here.

[zurfyx]

Thanks: B's node now opens a run of its own (B inserts it inside plain ab cd), so the token, segmented and bold token cases fail on main. The "before" placement passes for every kind since 0f080d9 (the cursor no longer steps past any item of another node's opening write). The "after + undo" cases for hashtag, code highlight, token and segmented text are test.fails naming #9586: only a tab's type is owned (904c01c explains why: line-dependent types must follow their run).

[meta-code-review]

With the reader change, a stored line whose two tabs had collapsed into one now shows both, so "Documents written before this fix keep how they read" is not quite accurate. CONTRIBUTING.md asks a fix that changes observable behaviour to say what to verify; worth adding that case here.

[zurfyx]

Updated: the Verify: paragraph now says a stored line where two tabs were shown as one shows both tabs, and that a link or format removed around a tab at the same time stays removed.

[meta-code-review]

Thanks for the follow-ups. The fixes are well covered: against main, the new TabLeak.test.ts fails the 12 tab, token/segmented and two-tab cases, and they pass on this branch. Deferring the hashtag, code highlight and token/segmented "after" cases to #9586 as test.fails makes sense.

Please fix: wrapper items of another node's opening write are now owned

opensNodeRun (packages/lexical-y/src/internal/Cursor.ts:274-293) counts every item of the write that opened a node's run, wrapper items included, and minimizeFormatChanges (line 495) stops stepping over them. A node's write lists its wrapper items first (packages/lexical-y/src/internal/Inline.ts:181), so content inserted inside a link right before a hashtag, tab or token that opened that link in the same write gets a w:link item of its own. That item survives the link author's undo and a collaborator's concurrent unlink, so the link stays on the inserted content on every peer, where main removes it (three peers, both client id orders):

B inserts after ab	A inserts inside the link, before B's first child	Then	main	this branch
link(#BB " more")	text XY	B undoes	no link	link("XY")
link(#BB)	text XY	C unlinks	no link	link("XY")
link(tab "zz")	a tab	C unlinks	no link	link(tab)

This contradicts the changeset's Verify: line ("A link or format a collaborator removes around a tab at the same time stays removed"). Typing, Tab and paste at a link's start put the content before the link, so it takes a node-level insert such as insertBefore inside the link, but once written it persists. For a typed node (tab, hashtag, code highlight token), wrapper items are the only ones opensNodeRun newly protects, since its t item comes right after them and was already never stepped past, so letting the cursor step over wrapper items keeps the token/segmented fix:

isFormat(r) &&
  this.unitGives(r, formats) &&
  (keyOf(r).startsWith(WRAPPER_PREFIX) || !opensNodeRun(r))

With that change the three cases end without a link, as on main, and the tests in TabLeak.test.ts still pass. Please add the three cases to TabLeak.test.ts, for example:

t.b.update(() => {
  const [left] = ($block([0]).getFirstChild() as TextNode).splitText(2);
  left.insertAfter(
    $createLinkNode('https://example.com').append($createTabNode(), $t('zz')),
  );
});
await t.sync();
t.offline();
t.a.update(() => {
  const tab = $block([0]).getAllTextNodes().find(n => n.getType() === 'tab')!;
  tab.insertBefore($createTabNode());
});
t.c.update(() => {
  const link = $block([0]).getChildren().find($isLinkNode)!;
  for (const child of link.getChildren()) {
    link.insertBefore(child);
  }
  link.remove();
});
await t.sync();
// every peer: no link left in the line

Smaller suggestions

• .changeset/lexical-y-own-segment-run.md:5: hashtags and code highlight tokens written right before a collaborator's node already kept their type on main (their write opens with the t item the cursor never stepped past, and their "before" cases pass on main); only token and segmented text lost their mode there. CONTRIBUTING.md asks for the changelog entry to be written for someone who uses Lexical, so naming token and segmented text only keeps it accurate.
• The Description's opening still describes the first commit's rule ("items of its own for every key it has", "a node written before a collaborator's was already safe"). AGENTS.md asks the Description to say what the change makes the code do; folding the two follow-up sections into it keeps that accurate.
• Consecutive Tab presses by one person now store two more format items each: eight presses at the end of a line store 26 live format items against 18 on main. A client's own undo removes its later write first, so its own run needs no owned type; returning null from ownSegmentKeys when the segment opener is the local client's (opener.id.client === this.tr.doc.clientID) brings that back to 18 while the new tests still pass.

[meta-code-review]

This also stops the cursor from stepping over wrapper items (w:*) of another node's opening write. A node's write lists its wrapper items first (Inline.ts:181), so content inserted inside a link right before a hashtag, tab or token that opened the link in the same write gets a w:link item of its own, which survives the link author's undo and a collaborator's concurrent unlink: the link stays on that content on every peer, where main removes it. For a typed node the wrapper items are the only ones this newly protects (its t item comes right after them and was never stepped past), so stepping over them keeps the token/segmented fix:

(keyOf(r).startsWith(WRAPPER_PREFIX) || !opensNodeRun(r))

[zurfyx]

Fixed in 3418a1e: minimizeFormatChanges steps over wrapper items again (keyOf(r).startsWith(WRAPPER_PREFIX) || !opensNodeRun(r)), so content written inside a link right before a node that opened it shares the link. Your three cases are in TabLeak.test.ts ("content written inside a link right before a node that opened it", three clients, both orders) and pass, as do the token/segmented "before" cases. Also from this review: the changeset now names token and segmented text only for the "before" placement, the Description is rewritten to say what the PR does now, and a tab after a tab of the same client owns nothing (eight Tab presses store 18 format items again). The same commit drops the 64-item cap on recognizing a tab's opening write (a tab with 128 comment ids lost its type after its author's undo).

[meta-code-review]

Hashtags and code highlight tokens written right before a collaborator's node already kept their type on main (their write opens with the t item the cursor never stepped past, and their before cases in TabLeak.test.ts pass on main); only token and segmented text lost their mode there. Since this line becomes the CHANGELOG.md entry (CONTRIBUTING.md), naming only token and segmented text keeps it accurate.

[meta-code-review]

Nit: this also owns the type inside a run the local client opened, so consecutive Tab presses store two more format items each (eight presses: 26 live format items against 18 on main). A client's own undo removes its later write first, so returning null when opener.id.client === this.tr.doc.clientID keeps the fix for other clients' runs and the old size for one's own.

[meta-code-review]

This looks good to me. The fix is well targeted, and the new TabLeak.test.ts cases fail against main's source and pass on this branch, and the link and format cases raised in earlier rounds are covered by tests. A few optional, non-blocking suggestions:

1. Consecutive Tab presses are not covered yet (packages/lexical-y/src/internal/Cursor.ts:589)

A tab owns its type only when the type comes from the segment author's own write. When a collaborator presses Tab twice (two updates), their second tab writes only its segment key inside their first tab's run, so a tab written after that second tab still reads its type from the first press's write. If the collaborator then undoes both presses (one undo step inside the default 500 ms captureTimeout, or two undos), that tab becomes a "\t" in the text before it on every peer. This is the same on main, so it is not a regression. A test in the style of TabLeak.test.ts that shows it:

test("B's tab after A's second consecutive Tab press survives A's undo", async () => {
  const t = await setup(() =>
    $getRoot().append(
      $createParagraphNode().append($t('ab cd')),
      $createParagraphNode().append($t('next line')),
    ),
  );
  const $lastTab = () =>
    $block([0])
      .getChildren()
      .filter(n => n.getType() === 'tab')
      .pop()!;
  t.a.update(() => {
    const [left] = ($block([0]).getFirstChild() as TextNode).splitText(2);
    left.insertAfter($createTabNode());
  });
  t.a.update(() => $lastTab().insertAfter($createTabNode()));
  await t.sync();
  t.b.update(() => $lastTab().insertAfter($createTabNode()));
  await t.sync();
  t.a.undo();
  t.a.undo();
  await t.sync();
  for (const peer of t.peers) {
    // On this branch and on main the line reads as one text node "ab\t cd".
    expect(
      peer.read(() => $block([0]).getChildren().map(n => n.getType())),
    ).toEqual(['text', 'tab', 'text']);
  }
  await expectConverged(t.peers);
});

Owning a tab's type whenever its source item is another client's (source.id.client !== this.tr.doc.clientID in place of this.oneWrite(opener, source)) makes this test pass, while the rest of TabLeak.test.ts and the @lexical/y unit tests still pass; one client's eight Tab presses written after another client's tabs then store 19 format items instead of 16. If you prefer to keep the narrower rule, a test.fails next to the #9586 cases would record the gap.

2. Changeset wording (.changeset/lexical-y-own-segment-run.md:5)

The first line becomes the CHANGELOG entry (.changeset/README.md), and as written it also promises the consecutive-Tab case. If the rule stays as it is, consider narrowing it to a tab written right after a collaborator's single Tab press.

3. Comment ids after the tabs in the many-ids test (packages/lexical-y/src/__tests__/unit/TabLeak.test.ts:833)

With 128 comment ids on B's tab, after B's undo the text after the tabs (" two") carries all 128 of B's comment ids on every peer. This also happens on main, so it is not caused by this PR: A's restore of B's values gets no end of its own because changeEnd only looks 64 items ahead (Cursor.ts:153-173), and B's undo removes the only closers; widening that window removes the leak and keeps TabLeak.test.ts passing. Asserting the comment ids of " two" in this test would catch it; a follow-up issue seems like the right place for the fix.

[meta-code-review]

Optional, non-blocking: this owns a tab's type only when it comes from the segment author's own write. A collaborator's second consecutive Tab press writes only its segment key inside their first tab's run, so a tab written after it still reads its type from the first press's write, and when the collaborator undoes both presses it becomes a "\t" in the text before it on every peer (the same on main). source.id.client !== this.tr.doc.clientID here covers that case while TabLeak.test.ts and the @lexical/y unit tests still pass; a test.fails beside the #9586 ones would also record it.

[zurfyx]

Confirmed: after a collaborator's second consecutive Tab press the type comes from the first press's write, so the tab written after it does not own it. Tracked in #9604 with a repro; owning the type across writes of the same client needs its own proof first, so it is left out of this PR.

[meta-code-review]

Optional: this line becomes the CHANGELOG entry (.changeset/README.md). As written it also covers a tab written after a collaborator's second consecutive Tab press, which still turns into a "\t" when they undo both presses (see Cursor.ts:589). If the rule stays as it is, consider narrowing it to a collaborator's single Tab press.

[zurfyx]

Narrowed in f953cf4: the entry and the Verify: line now name a tab a collaborator added with one Tab press; the double press is #9604.

[meta-code-review]

Optional: with 128 ids, after B's undo " two" carries all 128 of B's comment ids on every peer (also on main: changeEnd only looks 64 items ahead, so A's restore of B's values gets no end of its own). Asserting the comment ids of " two" here would catch it, probably in a follow-up.

[zurfyx]

Pre-existing on main, as you say (changeEnd only looks 64 items ahead), so it is tracked in #9603 rather than asserted here.