[Bug] Desktop app Claude Code tab: inline \( ... \) math silently fails above 58 characters

Correction to the threshold, and confirmation of scope.

The bound is not 58 characters of content. It is 60 characters between \( and \), counting whitespace. 58 is what you get in the conventional padded style \( x \), which is what every measurement in the original report happened to use.

Three padding styles, same ladder, one character of resolution:

| form | last length that renders | first that fails | content + padding |
|---|---|---|---|
| \(CONTENT\) | 60 | 61 | 60 |
| \( CONTENT\) | 59 | 60 | 60 |
| \( CONTENT \) | 58 | 59 | 60 |

Each row sums to exactly 60. Whitespace inside the delimiters consumes budget, so the rule is a flat 60-character cap on the span interior — equivalently a 64-character cap including the two delimiters. That is consistent with a bounded quantifier such as .{0,60} in whatever matches the span.

Reproduction, unpadded form. The first renders, the second does not:

\(\mathbb{Z} = abcdefghijabcdefghijabcdefghijabcdefghijabcdefg\)
\(\mathbb{Z} = abcdefghijabcdefghijabcdefghijabcdefghijabcdefgh\)

Scope confirmed. The chat pane and the plan pane behave identically — in chat, the padded 58 renders and 60, 64, 72 and 90 all fail. So the title is right that this is the Claude Code tab as a whole, not one pane. Display math is unaffected at every length tested.

The impact point in the original report gets sharper with the corrected bound: padding the delimiters in the conventional way costs two of the sixty characters, so the most readable source form is also the one with the least budget.

Same app build, second platform: reproduces on Windows 11.

Machine two: Claude desktop app 2.110.0 on Windows 11 Enterprise 25H2
(10.0.26200, x64). That is the same app build as the macOS 26.7 machine in the
original report, so this is not a separate platform's bug — one build shows an
identical bound on both, which points at the shared span matcher rather than
anything OS-specific. platform:macos should come off.

The full ladder, both padding styles bracketed at one-character resolution:

| rung | form | interior | result |
|---|---|---|---|
| A | \( x \) | 60 | renders |
| E | \( x \) | 61 | fails |
| C | \(x\) | 60 | renders |
| D | \(x\) | 61 | fails |
| B | \( x \) | 62 | fails |

A: \( \mathbb{Z} = abcdefghijabcdefghijabcdefghijabcdefghijabcde \)
B: \( \mathbb{Z} = abcdefghijabcdefghijabcdefghijabcdefghijabcdefg \)
C: \(\mathbb{Z} = abcdefghijabcdefghijabcdefghijabcdefghijabcdefg\)
D: \(\mathbb{Z} = abcdefghijabcdefghijabcdefghijabcdefghijabcdefgh\)
E: \( \mathbb{Z} = abcdefghijabcdefghijabcdefghijabcdefghijabcdef \)

Rung E is new. The padded ladder in my earlier comment stopped at B, which is two
characters over the bound rather than one, so the padded form's edge was never
pinned at single-character resolution. E supplies it. The 60-renders / 61-fails
boundary now holds independently for the padded and the unpadded form — which is
what a flat 60-character cap on the span interior predicts, and what a
"58 characters of content" reading does not.

All five rungs were checked in the chat pane and the plan pane on this machine
and agree.

One convenience for anyone confirming this: selecting and copying the lines
separates the cases without squinting at glyphs. A rendering rung copies as the
rendered text followed by its LaTeX source; a failing rung copies as bare
parentheses around the raw source.

Scope narrows further: the Chat surface of the same build is unaffected.

Same machine and same binary as my previous comment — Claude desktop app 2.110.0
on Windows 11 Enterprise 25H2 (10.0.26200, x64). Pasted into the desktop app's
Chat surface rather than the Code tab, all five rungs render, including the
three that fail in the Code tab at interiors 61 and 62.

So the 60-character bound is not the operating system, not the app shell, and
not a component shared across surfaces — it is specific to the Code tab's own
rendering path. (Browser claude.ai is untested; this is the desktop app's Chat
surface only.)

Display math also holds up under more testing than the original report gave it.
In the Code tab, $$ ... $$ renders at interiors of 251, 691, 1351 and 2231
characters as multi-line aligned blocks, and at 426 and 1895 characters as a
single long horizontal expression — in the chat pane and the plan pane alike,
with only horizontal scrolling at the wide end. The defect is isolated to
inline \( ... \).