You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Add a thread-header width control with 5% steps and Fit tables #12784
Wide screens leave much of the chat pane unused because messages and the composer stay capped at 48rem. Wide tables can still require horizontal scrolling through long, single-line cells.
Could the thread header offer a Width control from 0–100% in 5% steps, plus Fit tables in the same popover?
0% keeps the original width; 100% uses the available chat pane, including with a right panel open.
Messages and the composer expand together. Both preferences persist on the device.
Fit tables wraps cells; tables with many columns still scroll to keep cells readable. Turning it off restores the existing per-table expand/collapse behavior.
Related: Discussion #10925 and #11594 already address chat width. This is an alternative interaction: direct header access and 5% adjustments, paired with table fitting, rather than Comfortable/Wide/Full presets in Settings.
Current layout
Proposed: 100% + Fit tables
Captured from an isolated dev app with synthetic content at the same 1920×956 viewport.
Supporting this — on a 3440px-wide monitor the fixed 48rem column is the biggest usability problem I have with T3 Code: most of the window is empty and wide content still scrolls horizontally. A Width control in the thread header also seems like a better home for this than a settings row, since it is a per-view decision.
Implementation note: TIMELINE_CONTENT_MAX_WIDTH = 768 in MessagesTimeline.logic.ts also drives the minimap gutter (resolveTimelineMinimapHasPersistentGutter, resolveTimelineMinimapHitStripWidth). At 100% width those helpers still assume a 768px centered column, so the hover strip extends the full 40px over the message text and swallows pointer events. The control should feed the effective width into those helpers, or they should measure the lane element.
Wide Markdown tables are a recurring readability problem for me. Columns become very wide, and reading across a row requires horizontal scrolling even when there is unused space in the window margins. This makes comparing information frustrating.
In my example, an assistant produced a table describing how game entities are stored. The rightmost column extends outside the visible chat area.
I’d like a long-term way to make these tables readable within the available screen space. Letting tables expand beyond the normal text width when space is available, wrapping cells more effectively, or providing a “Fit tables” option could help. I’m open to other designs; the goal is comfortable reading with less horizontal scrolling.
Another option would be clicking a table to open an expanded preview, similar to an image preview modal, with a full-screen option. That would give larger tables more space while preserving the normal chat layout.
Version observed: unconfirmed. The locally installed desktop CLI reports 0.0.46-nightly.20261013.3080.
Local environment: Omarchy Linux.
Prepared by Codex (GPT-6) using the T3 Code triage playbook.
make sure the right panel gets the same treatment, whatever the solution; Sucks to open a markdwon in the right panel and have the same narrow content width limitation.
Thanks for the report. One part of this is fixed on main in #11594 and #20878. Please test on the nightly built from main on 2026-10-21, or on the next stable release. One part is still open: There is no per-thread-header width control with 5% steps. If that part still matters to you, please open a new issue for that part only.
Activity
v1b3coder commentedon Sep 22, 2026
Supporting this — on a 3440px-wide monitor the fixed 48rem column is the biggest usability problem I have with T3 Code: most of the window is empty and wide content still scrolls horizontally. A Width control in the thread header also seems like a better home for this than a settings row, since it is a per-view decision.
Implementation note:
TIMELINE_CONTENT_MAX_WIDTH = 768inMessagesTimeline.logic.tsalso drives the minimap gutter (resolveTimelineMinimapHasPersistentGutter,resolveTimelineMinimapHitStripWidth). At 100% width those helpers still assume a 768px centered column, so the hover strip extends the full 40px over the message text and swallows pointer events. The control should feed the effective width into those helpers, or they should measure the lane element.nelsonsbrian commentedon Oct 18, 2026
Wide Markdown tables are a recurring readability problem for me. Columns become very wide, and reading across a row requires horizontal scrolling even when there is unused space in the window margins. This makes comparing information frustrating.
In my example, an assistant produced a table describing how game entities are stored. The rightmost column extends outside the visible chat area.
I’d like a long-term way to make these tables readable within the available screen space. Letting tables expand beyond the normal text width when space is available, wrapping cells more effectively, or providing a “Fit tables” option could help. I’m open to other designs; the goal is comfortable reading with less horizontal scrolling.
Another option would be clicking a table to open an expanded preview, similar to an image preview modal, with a full-screen option. That would give larger tables more space while preserving the normal chat layout.
Version observed: unconfirmed. The locally installed desktop CLI reports
0.0.46-nightly.20261013.3080.Local environment: Omarchy Linux.
Prepared by Codex (GPT-6) using the T3 Code triage playbook.
bman654 commentedon Oct 19, 2026
make sure the right panel gets the same treatment, whatever the solution; Sucks to open a markdwon in the right panel and have the same narrow content width limitation.
t3dotgg commentedon Oct 21, 2026
Note
🤖 Claude Opus 5.5 responding on behalf of Theo
Thanks for the report. One part of this is fixed on main in #11594 and #20878. Please test on the nightly built from main on 2026-10-21, or on the next stable release. One part is still open: There is no per-thread-header width control with 5% steps. If that part still matters to you, please open a new issue for that part only.