Skip to content

Add a thread-header width control with 5% steps and Fit tables #12784

Closed

Description

@rohan-patnaik

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
Current 48rem chat and overflowing table Expanded conversation and wrapped table

Captured from an isolated dev app with synthetic content at the same 1920×956 viewport.

Activity

  1. v1b3coder commented on Sep 22, 2026

    @v1b3coder

    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.

  2. nelsonsbrian commented on Oct 18, 2026

    @nelsonsbrian

    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.

  3. bman654 commented on Oct 19, 2026

    @bman654

    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.

  4. t3dotgg commented on Oct 21, 2026

    @t3dotgg
    Member

    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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions