Wide markdown tables collapse into stacked key-value cards instead of rendering as tables

Found 1 possible duplicate issue:

1. https://github.com/anthropics/claude-code/issues/24949

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

The previous issue was closed without resolution.

+1, hitting this regularly in real workflows. Real-world example from today: I asked Claude to compare four rate-limiting libraries across four attributes. Valid markdown table in the model output, but rendered in the CLI like this:

Option: slowapi
Async-native: bolted-on (sync-first port of Flask-Limiter)
Redis backend: yes, via limits
Maintenance: active but light recent activity
Setup: decorator-based, easy
────────────────────────────────────────
Option: fastapi-limiter
Async-native: yes (designed async-first)
Redis backend: yes (atomic Lua)
Maintenance: active
Setup: @RateLimiter(...) decorator
────────────────────────────────────────
Option: limits lib directly
…

For a 4-row × 5-column comparison this turns one scannable table into ~25 lines of stacked cards, which defeats the entire point of using a table — there's no way to visually align across rows to spot differences.

A few possible directions:

1. Allow horizontal scrolling for wide tables (similar to less -S).
2. Fall back to plain monospaced column-aligned text (the column -t look) when GFM rendering would overflow — uglier than a real table but preserves the row-by-row alignment.
3. Wrap long cells with line breaks within the cell rather than collapsing the whole row — same column -t columns, each cell becomes a multi-line block, the row separator stays a single horizontal rule. Preserves alignment and readability simultaneously.

Im also hitting this, wrapping long cells was my first instinct. The workaround I am using is zooming out until the table has space to render but this not ideal.

Reproducing on Claude Code 2.1.140, macOS, Apple Terminal. Same stacked key-value fallback fires on any table with cells over ~25 chars, even at 3 columns — column count isn't the trigger, total rendered width is.

Concrete case from today: asked Claude to summarize a Pulumi stack — 18 resources × 3 columns (URN suffix / type / description). Pulumi URNs are inherently 40-60 chars (e.g. aws:secretsmanager/secretVersion::ue5-github-pat-version), so the table immediately tripped the fallback and rendered as ~90 lines of stacked cards with URN suffix: / Type: / Resource: labels repeated on every record. Genuinely unscannable.

Notable diagnostic: a fenced code block with manually-aligned monospace columns renders the exact same data perfectly, because it bypasses the markdown table renderer entirely. So the terminal is fully capable of displaying wide tabular content readably — the bug is specifically in the table renderer's fallback behavior, not a terminal-width limit. Any of the proposals in this thread (horizontal scroll, intra-cell wrap, column -t style, raw markdown passthrough) would be strictly better than collapsing rows into stacked cards. The current behavior makes structured infra/cloud output (Pulumi/Terraform/AWS/k8s listings) categorically unreadable, which is a meaningful share of Claude Code workloads.

This issue was fixed as of version 2.1.141.

Still hitting this on 2.1.141 (which claude --version confirms is what I'm running), so the fix doesn't appear to cover all cases. macOS, iTerm2 + tmux this time.

Worth noting up front: the fix did partially land. On smaller tables I'm now seeing intra-cell line wrapping work correctly — long cells break across multiple lines within the cell while the row/column alignment is preserved, which is exactly proposal #3 from my earlier comment. So whatever was shipped in 2.1.141 is doing the right thing in some cases. It just doesn't fire on wider tables, which still fall back to the old stacked-card behavior.

Example from today — I asked Claude to compare a proposed quantization scheme against the current one across 8 dimensions. The model emitted a 4-column × 8-row markdown table (Dimension / Current INT8 / TurboQuant 4-bit / Delta). The CLI rendered it like this:

TurboQuant 4-bit vs current INT8 — head-to-head

Pros

Dimension: Compression (quantized vectors)
Current INT8: 4× (1024 B/vec on Jina v3)
TurboQuant 4-bit: 8× (512 B/vec)
Delta: −50% quantized RAM
────────────────────────────────────────
Dimension: Recall
Current INT8: ~99% (excellent on normalized DOT)
TurboQuant 4-bit: ≈INT8 in Qdrant's bench
Delta: Wash, possibly +. Rotation acts as a "whitening" that often helps anisotropic
  embeddings.
────────────────────────────────────────
Dimension: Outlier handling
Current INT8: Manual quantile=0.99 clip
TurboQuant 4-bit: Automatic via random rotation → Beta distribution per coordinate
Delta: Less to tune, harder to misconfigure
────────────────────────────────────────
Dimension: Asymmetric scoring
Current INT8: Symmetric (both sides INT8)
TurboQuant 4-bit: Asymmetric, automatic (query stays float32)
Delta: Lower quantization error on query side
────────────────────────────────────────
…

Exact same stacked-card fallback as before — Dimension: / Current INT8: / TurboQuant 4-bit: / Delta: labels repeated on every row, horizontal rules between records, no way to scan across rows to compare a single dimension. (And to rule out tmux narrowing the reported width: the pane is 200+ cols wide here, so it's not a width-detection issue.)

So it looks like the new intra-cell wrap renderer has a threshold — column count, total cell length, or something — above which it gives up and falls back to the old stacked-card path instead of just wrapping more aggressively. Whatever that threshold is, this 4×8 table is on the wrong side of it, and the same table would clearly be readable if intra-cell wrap had stayed engaged.

This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.