Codex Terminal is sort of clipped. can't write, can't scroll.

[harshitsinghbhandari]

[harshitsinghbhandari]

Triage / likely RCA (hypothesis, not a confirmed fix)

Symptom: The Codex terminal renders only in the top ~half of the pane; the cursor sits at a horizontal divider mid-pane, everything below is empty bg-terminal black, and the user can't type or scroll.

What the geometry tells us. The empty region is inside the terminal pane, not a sibling panel: the session split is horizontal (terminal left / inspector right), so nothing lives below the terminal (SessionView.tsx:147-152, CenterPane.tsx:11-18). The host element is height: 100% and .xterm { height: 100% } (XtermTerminal.tsx:199, styles.css:192-194), so the black band below is the host showing through under a grid that has too few rows — the cursor is parked on the grid's last row.

Crucially, in the screenshot the columns look correct (the Ran ao spawn … line spans the full pane width) while the rows are roughly halved. A uniform devicePixelRatio mis-scale would shrink both axes, so this is not a generic HiDPI scale bug. It points specifically at the vertical cell metric: xterm measured the cell height too large, so FitAddon divided the pane height by an inflated cell height and produced ~half the rows. That row count is then sent verbatim to zellij over the mux (useTerminalSession.ts:201-202 open + resize with terminal.cols/rows; terminal-mux.ts open{id,cols,rows} / resize{id,cols,rows}), so the server-side zellij attach is told it has ~half the rows and paints only the top half. "Can't write / can't scroll" follows: the live prompt + zellij status bar sit on rows below the grid's last painted row (off the visible region), and wheel/mouse reports map into a grid that never extends into the empty area.

Prime suspects for the inflated cell height (XtermTerminal.tsx):

1. lineHeight: 1.35 (line 111) combined with the WebGL renderer being loaded after term.open() (lines 143-144). The non-integer line height plus the post-open renderer swap is exactly where cell-height rounding/measurement is fragile, and a tall Nerd Font glyph box (font stack resolved from --font-mono, lines 107-109) can make the measured line box come out high.
2. Measure-before-metrics timing. The component's own header comment already documents the horizontal version of this failure ("if it measures before the monospace font's real metrics are resolved it over-counts columns", lines 11-16). The rows symptom here is the same measure-timing family, just on the vertical axis.

Why it never recovers (the structural gap that makes it stick). Fit runs on a fixed settle window — requestAnimationFrame, setTimeout(50), setTimeout(250), and document.fonts.ready (XtermTerminal.tsx:155-159). After that window the only remaining trigger is a ResizeObserver on the host (lines 160-161). But the host's pixel box is height:100% of a stable pane and does not change when the grid row-count is wrong, so the observer never fires and the bad grid is frozen for the session's lifetime. This matches the report that the state is stuck rather than self-correcting. (Consistent corollary: resizing the OS window — which does change the host box — would likely fix it temporarily, a useful thing to confirm.)

Suggested verification (cheap, would confirm/refute):

• In DevTools on a clipped pane, compare term.rows against Math.floor(hostHeight / measuredCellHeight) and inspect term._core._renderService.dimensions.css.cell.height vs the expected ~fontSize*lineHeight. If css.cell.height is ~2× expected, that confirms the cell-height over-measure.
• Trigger a window resize and see whether the grid snaps to full height — confirms the "no post-settle re-fit" gap.
• Check window.devicePixelRatio on the affected machine (Retina/non-integer scaling is the usual aggravator for cell-height rounding).

Where a fix would most plausibly live (for a follow-up, not asserting it here): force a fit (or re-fit) once the renderer has computed real dimensions and once document.fonts.ready resolves with a non-zero cell height, and/or add a recovery trigger that isn't gated on the host box changing size (e.g. re-fit on term.onRender until the proposed grid stabilises, or a window resize / dpr-change listener). Revisiting the lineHeight: 1.35 / renderer-load-order interaction is also worth it.

Happy to dig into any of the verification steps above to firm this up.