[FEATURE]: Add tui.json option to control content area max-width / horizontal padding

[alohaninja]

Description

After a recent upgrade, the horizontal margins/padding on the main content area in the TUI appear to have increased, making the readable content area noticeably narrower — especially on wide terminals. Tables and long-form output get compressed while there's unused space on either side.

This was previously raised in #838, which was closed without a user-facing config option being added.

Request

Add a tui.json option (e.g. content_max_width or content_padding) that lets users control how wide the main response content area renders. Something like:

// tui.json
{
  "content_max_width": 0, // 0 = full terminal width
  "content_padding": 1    // horizontal padding in columns
}

Currently tui.json supports scroll_speed, diff_style, mouse, etc. — but nothing for layout/spacing of the content area.

Current behavior

• Content area has fixed left/right margins that cannot be overridden
• The theme system only controls colors, fonts, and syntax highlighting — not layout
• No documented workaround exists for adjusting content width

Expected behavior

• Users can configure the content area width through tui.json
• Sensible default preserved, but overridable for users with wide terminals

Environment

• OS: macOS
• Terminal: wide-screen setup

[alohaninja]

Draft PR with a minimal implementation: #25146

Adds a content_padding option to tui.json (integer, 0–20, default 2) that controls the horizontal padding on the main session content area. Two files changed, backward-compatible — existing behavior is preserved unless the user opts in.

All CI checks are passing.

[alohaninja]

Updated PR with proper template (previous one was auto-closed for not following the PR template): #25171

All CI checks passing including compliance.

[Mehdi-afs]

I am using desktop open code on Mac and my problem is that the code diff is always stacked, even when there's wide enough space to show them side by side. I hate this stacked view, but I could not find any option that allow me to change it.

[7nicetoseeu]

Thanks for tracking this — I ran into the same wasted-space problem on wide terminals and did a bit of source reading before finding this issue. Sharing what I found in case it helps scope the implementation; happy to open a PR if useful.

In packages/tui/src/routes/session/index.tsx, the effective content width is driven by two hardcoded values:

// index.tsx:265
const wide = createMemo(() => dimensions().width > 120)
// index.tsx:273
const contentWidth = createMemo(() => dimensions().width - (sidebarVisible() ? 42 : 0) - 4)

So on a wide terminal the sidebar auto-shows at width > 120 and consumes 42 columns, and there's a fixed - 4 (the paddingLeft/Right={2} on the message container at index.tsx:1168-1169). Messages themselves have no maxWidth — they fill contentWidth.

A couple of things that look like good news for implementation:

1. There's already a precedent for a width cap in the TUI config: prompt.max_width (a positive int or "auto") in packages/tui/src/config/index.tsx:48, consumed in routes/home.tsx:33-37. A content_max_width with the same shape would be consistent.
2. The main-config layout ("auto" | "stretch") is already @deprecated and forced to stretch (per https://opencode.ai/config.json), so the stretch behavior is settled and a width cap would layer on top cleanly.

My read is that #6087 (sidebar width) and #20230 (padding) are the other two levers on the same contentWidth line, so the three issues could plausibly be addressed together with a small tui.json surface (e.g. content_max_width, sidebar_width, content_padding). But I'll defer to whoever picks this up on whether to do them in one pass or separately.

If a PR is welcome, I'd suggest starting with content_max_width (smallest, matches the existing prompt.max_width pattern). Let me know and I can put it up.

[7nicetoseeu]

Following up with the desktop app (packages/app) side of this, since the wasted-space problem shows up there too and the root cause is a separate code path from the TUI.

In the desktop app the session message timeline is hard-capped and centered:

packages/app/src/pages/session/timeline/message-timeline.tsx:1013-1015

"min-w-0 w-full max-w-full": true,
"md:max-w-200 2xl:max-w-[1000px]": props.centered,   // cap at ~800px / 1000px
"md:mx-auto": props.centered,                          // center, leaving empty sides

The centered flag comes from packages/app/src/pages/session.tsx:181:

const centered = createMemo(() => isDesktop() && !desktopReviewOpen())

So on a wide desktop window with the review panel closed, the message column is forced to max-w-200 (~800px) / 2xl:max-w-[1000px] and horizontally centered — which is exactly the "large empty margins on both sides" complaint. The composer mirrors the same logic (session-composer-region.tsx:228).

This looks like the desktop-app equivalent of the TUI content_max_width ask in this issue. A single content_max_width setting (0 / int / "auto") that both the TUI (packages/tui) and the desktop app (packages/app) honor would resolve it uniformly. On the desktop side the change would be to feed the setting into the centered memo / the max-w-* classes in message-timeline.tsx and session-composer-region.tsx.

Happy to take this on (both sides, or just the desktop side) if a PR is welcome.

[AliAltivate]

I'll work on this. Plan: add an optional content_padding (horizontal padding in columns) option to tui.json, wired into the session content area with the current behavior as the default, following the existing config schema pattern.

[janplancraft]

@AliAltivate Any updates on this?