Inline code that wraps across lines renders as cut-off pills
Nobody has claimed this yet.
Assessment
- Difficulty
- 1/5
- Estimated time
- Under an hour
- Newbie friendliness
- 90/100
- Issue type
- Bug
- Clarity
- Clearly specified
- Activity status
- Active
- Tech stack
- css
- Domain
- frontend
Research direction
Inspect the inline-code selector in apps/web/src/index.css around lines 1792 or 1818 and reproduce the issue by resizing a chat column until a code span wraps. Verify the rendered fragments at the line break; this is done when both fragments retain the intended pill borders, radius, and horizontal spacing.
Written by the indexing model from the issue text.
Description
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
-
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`) -
Use a window or column width where the middle span wraps between "location" and "evidence".
-
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 at2026-09-16T06:55:00Z) contains a single inline code span forlocation 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
- #3142 (inline code typed on dead-key layouts renders literally): input-side problem, unrelated.
- #10787 (file-link chips discard Markdown labels): different component.
- #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.
- Dominant language
- TypeScript
- Stars
- 23.3k
- Forks
- 6k
- Avg merge
- 10h 57m
- Merged PRs (30d)
- 365
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from pingdotgg/t3code
-
bug via-triage
Difficulty 2/5 1-3 hours Newbie friendliness 74/100
-
accepted bug via-triage
Difficulty 2/5 1-3 hours Newbie friendliness 85/100
-
accepted bug via-triage
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
-
accepted bug via-triage
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
All issues in pingdotgg/t3code
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
copse-dev/agent-pane#2953 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
Eynzof/Hermes-CN-Desktop#610 ·
-
bug clawsweeper:linked-pr-open clawsweeper:needs-live-repro clawsweeper:no-new-fix-pr impact:message-loss issue-rating: 🐚 platinum hermit P2 regression
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
-
enhancement
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
-
calcite-components needs triage refactor
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
Esri/calcite-design-system#15203 ·