Inline code that wraps across lines renders as cut-off pills

[satyalyadav]

What happened

Inline code spans that wrap across a line break are sliced instead of re-decorated. The fragment ending the first line keeps its rounded left cap and then runs to the edge of the column with a flat, cut-off right side; the fragment starting the next line begins with no left cap and no left padding. A single span like location evidence reads as two separate, cut-off pills.

Rendered as it appeared in the chat (the break falls inside the second code span):

...and per-field evidence (`employer type`, `location
evidence`, `experience evidence`) that maps directly...

The reporter will attach the UI screenshot in a follow-up comment.

Impact: cosmetic. Text stays readable, but the chip looks broken at the wrap.

Diagnosis

The inline code rule in apps/web/src/index.css styles the pill but never sets box-decoration-break, so the browser uses the default slice. At a line break the box is fragmented and the border, radius, and horizontal padding are not repeated on the fragments.

At tag v0.0.42 (apps/web/src/index.css:1818), and at v0.0.40 (apps/web/src/index.css:1792) which the reporter is running:

.chat-markdown :not(pre) > code {
  border: 1px solid var(--contrast-border);
  border-radius: 0.375rem;
  background: var(--muted);
  padding: 0.1rem 0.35rem;
  color: var(--contrast-foreground);
  font-size: 0.75rem;
}

Searched v0.0.40, v0.0.41, and v0.0.42 for box-decoration-break: zero occurrences in apps/web/src/index.css. This is not fixed in the newest release.

Suggested fix:

box-decoration-break: clone;
-webkit-box-decoration-break: clone;

Steps to reproduce

1. In any thread, have an assistant message with an inline code span that contains a space and lands on a wrap boundary, for example:

   per-field evidence (`employer type`, `location evidence`, `experience evidence`)
   

2. Use a window or column width where the middle span wraps between "location" and "evidence".

3. The pill is sliced at the break: the first fragment bleeds to the right edge, the next line starts with a cut left side.

Resizing the chat column is enough. Any break that falls inside an inline code span shows the artifact.

Version

Desktop app 0.0.40 on a WSL2 backend (runtime hash 02c38816d0b6722af4ec74c48982ab009586fe7f84274cc757fe8f039c4784db). Checked against v0.0.42: the rule is unchanged, so the newest release still has this.

Environment

Windows 11 + WSL2 (Ubuntu), Node v24.18.0. T3 Code desktop app connected to the WSL-hosted server. Dark theme; the rule is theme-independent.

Evidence

• Stored message text (thread ae2f6577-eaa1-47fa-9769-7570705c79d6, assistant message at 2026-09-16T06:55:00Z) contains a single inline code span for location evidence. The split is layout, not parsing or streaming; the same message renders this way after the turn settles.
• Compiled CSS in the running runtime (main-C6VFPY8e.css):
  .chat-markdown :not(pre)>code{border:1px solid var(--contrast-border);background:var(--muted);color:var(--contrast-foreground);border-radius:.375rem;padding:.1rem .35rem;font-size:.75rem}
• Source references: apps/web/src/index.css:1792 (v0.0.40), apps/web/src/index.css:1818 (v0.0.42).

Related issues

• [Bug]: Inline code typed on dead-key keyboard layouts renders literally (non-ASCII grave instead of U+0060) #3142 (inline code typed on dead-key layouts renders literally): input-side problem, unrelated.
• [Bug]: File-link chips discard descriptive Markdown labels and remove sentence content #10787 (file-link chips discard Markdown labels): different component.
• [Bug]: Wide markdown tables overflow the chat lane with no visible scrollbar even when Word wrap is on #8705 (wide markdown tables overflow): different element.

Not a duplicate of any of these.

Fix applied or workaround

None applied. Workaround: widen the window until the span no longer wraps.

Filed by

opencode (deepseek-v4.1-flash), running the t3 triage playbook by hand.

[juliusmarminge]

Triage

Confirmed on current main (6ee03240b) and on shipping 0.0.42. This is a real web/desktop CSS bug, not a parse or streaming defect, and not a wash of #3142 / #10787 / #8705.

The stored span is one <code>. At a line break the pill is sliced: first fragment keeps the left radius and then runs flat to the column edge; the next line starts with no left cap and no left padding. Cosmetic only — the text stays readable.

What the code does

Inline code is a raw <code> (ChatMarkdown.tsx MarkdownCode). Path-like spans become MarkdownFileLink chips and leave this rule; ordinary spans like `location evidence` do not.

The pill lives in apps/web/src/index.css:

.chat-markdown :not(pre) > code {
  border: 1px solid var(--contrast-border);
  border-radius: 0.375rem;
  background: var(--muted);
  padding: 0.1rem 0.35rem;
  color: var(--contrast-foreground);
  font-size: 0.75rem;
}

No box-decoration-break. The used value is slice, so border, radius, and horizontal padding are not repeated on fragments. That is the cut-off look.

Wraps are easy because the markdown root also sets [overflow-wrap:anywhere] [word-break:break-word]. A space inside the span is enough; a long token will also break mid-word. The t3-chat theme overrides only color/background. Same slice on every theme.

Same rule, same miss, on every ChatMarkdown surface: assistant and user chat, file preview, plan cards, PR markdown. Desktop is the web stylesheet in Electron, so it matches. Mobile is out of scope: RN MarkdownInlineCode is mono + color, no pill chrome.

box-decoration-break does not appear in apps/web. Not fixed in v0.0.40, v0.0.42, or main.

Related, not duplicates

Issue / PR	Why it does not close this
Open #3142	Dead-key layouts type a non-ASCII grave, so the span never parses. Input, not decoration.
Open #10787	File-link chips drop Markdown labels. Different component (MarkdownFileLink).
Closed #8705	Wide tables overflow the lane. Different element.
Closed #221	List markers after Preflight. Same .chat-markdown sheet, different rule.

No open or merged PR adds box-decoration-break to this selector.

Suggested fix

Keep this as a two-line CSS bugfix on .chat-markdown :not(pre) > code only:

box-decoration-break: clone;
-webkit-box-decoration-break: clone;

The -webkit- prefix is what Chromium / Electron honor; the unprefixed line covers Firefox (hosted web). clone repeats border, radius, and padding on each fragment, so a wrap reads as two complete pills instead of one sliced box.

Do not “fix” this with white-space: nowrap or display: inline-block. Those keep one pill by refusing to wrap (or by overflowing), which fights [overflow-wrap:anywhere] and is worse for long tokens.

Leave file-link chips and <pre><code> alone. Theme overrides can stay color-only. No JS test: this is used-value CSS. A before/after screenshot at a wrap width is enough.

Workaround

Widen the chat column until the span fits on one line. No in-app toggle.

Classification: bug · accepted · cosmetic (web/desktop inline-code pills; wrap fragment uses slice)
Labels: add bug, accepted, via-triage
Discord tags: ui

[satyalyadav]

Screenshot from the report (desktop 0.0.40, dark theme): the location evidence span wraps between the two words, the first fragment runs flat to the column edge and the continuation starts with no left cap or padding.