[FEATURE] Prose-width capping, independent of terminal width

Problem Statement

On a wide display a full-screen terminal is ~200 columns, and Claude Code renders prose at that full width. Typography research converges on 50–75 characters per line for prose (Bringhurst; Legge & Bigelow 2011, Journal of Vision 11(5):8), so ~200 columns is roughly 3x the recommended upper bound.

The cost is retrace error: at that measure the eye struggles to locate the start of the next line, which accumulates as fatigue over a long reading session rather than showing up as an obvious defect. It is most noticeable when tired.

The width is not incidental — it is wanted for diffs, wide tables, and code. The problem is specifically that prose inherits it.

Proposed Solution

A setting that constrains prose narration only, leaving code blocks, command output, diffs, and tables at full terminal width.

Any of these shapes would work; I have no strong preference:

• a settings.json key, e.g. maxProseWidth: 100
• an environment variable, e.g. CLAUDE_CODE_PROSE_WIDTH=100
• a /config toggle

The important part is that it is prose-scoped. A blanket width cap would be worse than the status quo, because it would break side-by-side diffs and wide code — the content that justifies a wide terminal in the first place.

Alternative Solutions

What I currently do: narrow the multiplexer window on demand (tmux resize-window -x 100, bound to a key). This works, but it is blunt — it narrows code, diffs, and tables along with the prose, so it has to be toggled back and forth rather than left on.

Why soft-wrap does not solve this. #35905, #24224 and #43113 request emitting long lines and letting the terminal wrap. That is a genuinely useful change — it fixes clipboard fidelity and reflow on resize — but it does not address reading width, because the terminal still wraps prose at the full window width. The two are complementary rather than alternatives.

Prior art, disclosed rather than glossed. This has been asked for before and closed as duplicate without a canonical target being named:

• #28326, "Add config setting for max chat text width" — close to this request, including the same reading-width rationale and the same rejected workarounds.
• #12734, "Configurable Output Line Width for Accessibility" — filed on low-vision grounds citing ADA / Section 508.

I am filing again rather than commenting because those appear to have been folded into the soft-wrap thread, which by the argument above does not deliver width capping. If there is a canonical open issue for prose width specifically, I am happy for this to be closed against it — I could not find one.

Priority

Medium. A working local workaround exists, so a higher band would overstate it.

Feature Category

Configuration and settings.

Use Case Example

1. Reviewing a change over a long session on a 32-inch 6K display, terminal full-screen at ~201 columns. The width is there because diffs and wide tables need it.
2. Claude's explanatory prose between the code blocks renders at 201 columns — about 3x the comfortable measure.
3. After an hour or two, the prose is measurably harder to follow. The failure is losing your place on the return sweep, not being unable to read the characters.
4. With maxProseWidth: 100, prose renders at a comfortable measure while the diffs either side of it stay full width. No toggling.

Additional Context

Verified that no such setting exists (Claude Code 2.1.227, macOS):

• No CLAUDE_CODE_* environment variable controls output width. All ~450 were extracted from the binary and checked. The nearest names are false leads: CLAUDE_CODE_MAX_OUTPUT_TOKENS is tokens rather than columns, and CLAUDE_CODE_RELAUNCH_TERMINAL_SIZE concerns relaunch behaviour.
• No key in the settings.json schema, which validates strictly and raises unrecognized_keys — so there is nowhere for such a setting to be hiding under a name I did not guess.
• The width-adjacent identifiers in the binary are unrelated: maxWidth is the model image-input limit (2000x2000) and textWidth belongs to an embedded p5.js keyword list used by the syntax highlighter.

On specifying it in characters: Legge & Bigelow (2011) is the reason to express this as a character count rather than a pixel or point width — point size is a poor proxy for apparent size, since x-height as a fraction of em spans 0.28–0.58 across typefaces.

Filed via gh, so the issue-form sections are reproduced as headings above.