Before submitting
Area
apps/web
Steps to reproduce
- In any thread, have an agent emit a markdown table with ~4 columns where two columns contain prose (e.g. a ticket list with
#, Title, Blocked by, Delivers columns — the Delivers cells holding 1–3 sentences each, some with inline code spans).
- Ensure the Word wrap setting is ON.
- View the message on a desktop-width window.
Expected behavior
With word wrap on, the table fits the chat content lane (cells wrap), or — if it must overflow — the horizontal scrollability is visibly signaled.
Actual behavior
The table lays out wider than the chat content lane and gets clipped at the lane edge. The rightmost column is cut off mid-word, and because the overflow ScrollArea renders with hideScrollbars + scrollFade, there is no scrollbar affordance — the clipped edge reads as truncation, not "scroll me". Reading the last column requires discovering shift+wheel / trackpad horizontal scrolling per table. Meanwhile the window has large unused margins on both sides of the centered lane.
Why word wrap doesn't help here (code walk)
All references are main @ 1f8ed54.
The message column is a fixed centered lane — max-w-3xl mx-auto (apps/web/src/components/chat/MessagesTimeline.tsx:569), so ~768px regardless of window width.
Tables deliberately opt out of the chat's wrapping (apps/web/src/index.css:1817-1842):
.chat-markdown table {
width: 100%;
min-width: max-content; /* lays out at natural unwrapped width */
overflow-wrap: normal; /* restores word-boundary wrapping (per the comment, so
word-break: normal; columns can't collapse to single characters) */
}
.chat-markdown thead th { white-space: nowrap; } /* headers never wrap */
The Word wrap setting only seeds each table's initial expanded state (apps/web/src/components/ChatMarkdown.tsx:496-503). Expanded mode adds per-cell caps (index.css:1858):
.chat-markdown .chat-markdown-table-container[data-expanded="true"] td {
max-width: 24rem;
overflow-wrap: anywhere;
}
So each prose cell wraps within ~384px — but the table keeps min-width: max-content, headers stay nowrap, and 4 columns with two prose columns still sum to ~850–1000px > the 768px lane. Result: cells wrap internally while the table as a whole still overflows and clips.
Two aggravating details:
- The overflow container is
<ScrollArea chainVerticalScroll scrollFade hideScrollbars …> (ChatMarkdown.tsx:576-580) — genuinely invisible overflow.
- The footer "Expand table cells" toggle pins each header cell's
min-width to its measured collapsed width before expanding (ChatMarkdown.tsx:514-527), so interactively expanding can never let columns shrink to fit the lane even when wrapping would allow it.
Suggested fixes (any subset)
A — make expanded mode fit-to-lane (minimal): when data-expanded="true", drop the max-content floor and let headers wrap:
.chat-markdown .chat-markdown-table-container[data-expanded="true"] table {
min-width: 100%;
}
.chat-markdown .chat-markdown-table-container[data-expanded="true"] thead th {
white-space: normal;
}
Auto table layout then distributes the lane width and prose cells wrap; the existing overflow-wrap: normal on the table already prevents the single-character-column collapse the current design guards against. The header min-width pinning in toggleExpanded would also need to go (it works against fit-to-lane). Collapsed mode keeps today's nowrap + ellipsis + scroll behavior.
B — visible overflow affordance: when a table actually overflows, show the horizontal scrollbar (or an explicit "wider than view" indicator in the table footer chrome, next to Copy). Fade-only is undiscoverable with a mouse.
C — let wide blocks breathe: allow tables (and code blocks) to break out of the 48rem lane up to the available column width, e.g. max-width: min(max-content, available) centered — or expose a chat content-width setting (comfortable / wide / full). On wide windows the margins can absorb most real-world tables without any wrapping compromise.
A alone fixes the reported case; B is worth having regardless since collapsed-mode overflow remains legitimate.
Impact
Minor bug or occasional failure (but hits every agent-generated ticket/comparison table, which agents produce a lot)
Version or commit
Verified against main @ 1f8ed54; observed on a desktop build of the #2829 V2 branch (all cited code identical on main).
Environment
macOS 15, desktop app (also reproduces in the web UI)
Workaround
Per-table "Collapse table cells" footer toggle + shift+scroll; or zoom the window out.
Before submitting
Area
apps/web
Steps to reproduce
#,Title,Blocked by,Deliverscolumns — theDeliverscells holding 1–3 sentences each, some with inline code spans).Expected behavior
With word wrap on, the table fits the chat content lane (cells wrap), or — if it must overflow — the horizontal scrollability is visibly signaled.
Actual behavior
The table lays out wider than the chat content lane and gets clipped at the lane edge. The rightmost column is cut off mid-word, and because the overflow
ScrollArearenders withhideScrollbars+scrollFade, there is no scrollbar affordance — the clipped edge reads as truncation, not "scroll me". Reading the last column requires discovering shift+wheel / trackpad horizontal scrolling per table. Meanwhile the window has large unused margins on both sides of the centered lane.Why word wrap doesn't help here (code walk)
All references are
main@ 1f8ed54.The message column is a fixed centered lane —
max-w-3xl mx-auto(apps/web/src/components/chat/MessagesTimeline.tsx:569), so ~768px regardless of window width.Tables deliberately opt out of the chat's wrapping (
apps/web/src/index.css:1817-1842):The Word wrap setting only seeds each table's initial
expandedstate (apps/web/src/components/ChatMarkdown.tsx:496-503). Expanded mode adds per-cell caps (index.css:1858):So each prose cell wraps within ~384px — but the table keeps
min-width: max-content, headers staynowrap, and 4 columns with two prose columns still sum to ~850–1000px > the 768px lane. Result: cells wrap internally while the table as a whole still overflows and clips.Two aggravating details:
<ScrollArea chainVerticalScroll scrollFade hideScrollbars …>(ChatMarkdown.tsx:576-580) — genuinely invisible overflow.min-widthto its measured collapsed width before expanding (ChatMarkdown.tsx:514-527), so interactively expanding can never let columns shrink to fit the lane even when wrapping would allow it.Suggested fixes (any subset)
A — make expanded mode fit-to-lane (minimal): when
data-expanded="true", drop the max-content floor and let headers wrap:Auto table layout then distributes the lane width and prose cells wrap; the existing
overflow-wrap: normalon the table already prevents the single-character-column collapse the current design guards against. The headermin-widthpinning intoggleExpandedwould also need to go (it works against fit-to-lane). Collapsed mode keeps today's nowrap + ellipsis + scroll behavior.B — visible overflow affordance: when a table actually overflows, show the horizontal scrollbar (or an explicit "wider than view" indicator in the table footer chrome, next to Copy). Fade-only is undiscoverable with a mouse.
C — let wide blocks breathe: allow tables (and code blocks) to break out of the 48rem lane up to the available column width, e.g.
max-width: min(max-content, available)centered — or expose a chat content-width setting (comfortable / wide / full). On wide windows the margins can absorb most real-world tables without any wrapping compromise.A alone fixes the reported case; B is worth having regardless since collapsed-mode overflow remains legitimate.
Impact
Minor bug or occasional failure (but hits every agent-generated ticket/comparison table, which agents produce a lot)
Version or commit
Verified against main @ 1f8ed54; observed on a desktop build of the #2829 V2 branch (all cited code identical on main).
Environment
macOS 15, desktop app (also reproduces in the web UI)
Workaround
Per-table "Collapse table cells" footer toggle + shift+scroll; or zoom the window out.