Self-driving setup: checkbox labels and Confirm button overlap wrapped description text

[Ref34t]

Ran npx @posthog/wizard@latest self-driving against a real Laravel/Vue app (not a wizard-workbench fixture). Two separate screens in the same run showed the same rendering corruption.

1. Custom-scout proposal screen

What rendered:

□ NoSkip custom scouts; the built-in troop already covers this project.
□ WaSpeaks up when the fraction of feedback items that fail AI processing rises
  above its recent norm — catching AI driver outages, malformed payloads, or OpenAI/Gemini
□ WaSpeaks up when triaged feedback stops producing tickets at the expected rate,
  catching cases where a GitHub or Linear token has expired or the downstream API is down —
  failures that are silently swallowed and don't appear
Confirmror tracking.

Each option has a short bold label (No / Watch / Watch) followed by a description, with a Confirm (n) button below the list. Instead:

• The label merges directly into the first word of the description with no space: No + Skip custom scouts... → NoSkip; Watch + Speaks up... → WaSpeaks (only the first 2 characters of "Watch" survive).
• The Confirm button overlaps the wrapped tail of the last option's description: ...in error tracking. + Confirm → Confirmror tracking.

2. Issue-tracker integrations checklist

Same failure mode, different screen — tool names corrupted: Gitlab → Giteab, Rollbar → Rollbart, Zendesk → Zendeskdger.

Likely source: src/ui/tui/screens/WizardAskScreen.tsx — the screen renders both corrupted checklists. Looks like a fixed height/position assumption that doesn't account for the actual wrapped line count of longer option descriptions.

Version: PostHog Wizard v2.51.0

Screenshots to be attached.

[Ref34t]

Dug into this properly. My original diagnosis was wrong, and I found a much more specific reproduction condition. Correcting the record and adding what I found.

The trigger: resizing the terminal window mid-run

I resized the terminal while the wizard was running. Ink's resized() handler only clears the screen when the width decreases:

// ink.js
resized = () => {
    const currentWidth = this.getTerminalWidth();
    if (currentWidth < this.lastTerminalWidth) {
        // We clear the screen when decreasing terminal width to prevent duplicate overlapping re-renders.
        this.log.clear();
        ...
    }
    this.calculateLayout();
    this.onRender();
};

Widening the window skips the clear. Ink's own comment names the failure mode this guard exists to prevent — "duplicate overlapping re-renders" — which is exactly what the screenshots show. Height changes aren't handled at all.

To reproduce: run any wizard TUI screen and widen the terminal window while it's rendering.

What the corruption actually is

Not garbled characters — it's new text painted over an un-erased previous frame. I tested "shorter new string over longer old string, same row" against three of the corrupted lines. All three match character-for-character:

new text	previous text	predicted	observed
Reading project context (23)	Checking Self-driving access (28)	Reading project contextccess	exact match
Enabling products (17)	Checking GitHub connection (26)	Enabling productsonnection	exact match
Designing custom scouts for this product (40)	Scout troop: 3 active (general, product-analytics, revenue-analytics); 25 disabled (82)	...productanalytics, revenue-analytics); 25 disabled	exact match

So it's cursor/frame desynchronisation, not text wrapping. That also explains the Giteab / Rollbart / Zendeskdger labels in the second screenshot — same overwrite, different rows.

Correcting my original report

I initially guessed this was the fixed width={56} on the multi-select description Box. That's wrong, for three reasons:

1. Output clips every line to the terminal width. renderer.js builds the buffer at the root node's computed width and iterates for (x = 0; x < this.width; x++) with sliceAnsi. An over-wide child Box can't produce a line longer than the terminal, so the terminal-level auto-wrap I assumed can't happen.
2. The corruption appears on screens with no descriptions at all — the intro screen, the status lines, and the issue-tracker checklist (label-only options; WizardAskScreen only passes description through when one exists).
3. My terminal was ≥88 columns, where a 56-wide box overflows nothing.

I've closed the PR I opened against that theory.

Possibly related, separate finding

While tracing this I noticed the fullscreen-clear decision in onRender reads the previous frame's height while isFullscreen reads the current one:

const isFullscreen = stdout.isTTY && outputHeight >= stdout.rows;          // current frame
if (this.lastOutputHeight >= this.options.stdout.rows) { ...clearTerminal... }  // previous frame

Probing against a fake TTY at 88x24, rendering frames of 6 -> 40 -> 34 -> 5 -> 8 rows:

write# 5  payload=40 rows  prevFrame= 7  <== taller than terminal, no clear
write# 8  payload=34 rows  prevFrame=40  (clearTerminal)

A 40-row frame gets painted into a 24-row terminal with no clear, because the previous frame was short. In isolation it self-heals on the next frame, so I can't say it contributes to this bug — flagging it in case it's useful.

Caveat

I could not reproduce the corruption in a headless harness — ink-testing-library has no height constraint and hardcodes 100 columns, and my terminal emulator is an approximation. Everything above about the resize is inference from Ink's source plus the character-exact overwrite evidence, not a captured repro. The real-terminal reproduction steps are the resize ones at the top.

Happy to keep digging if it's useful — and happy to leave it if you'd rather take it from here.

[Ref34t]

Correction to my previous comment: the resize theory does not hold up. Retracting it before it wastes anyone's time.

I built a harness that renders a wizard-shaped Ink frame in a real terminal (alternate screen buffer, as start-tui.ts does), with a bottom status line alternating between an 82-character string and a 40-character one — so any failure to clear would immediately show the long tail behind the short line.

Resized the window wider and narrower repeatedly, through ~176 render ticks. No corruption at any width. So "widen the terminal mid-run" is not a reproduction, and the resized()-only-clears-on-shrink path is not sufficient on its own. Please disregard those steps from my last comment.

What still stands, unchanged:

• The symptom is a frame-clearing failure, not a wrapping failure. The three character-exact overwrite matches in my previous comment are unaffected by this — they're derived from the screenshots, not from the theory.
• The original width diagnosis is still wrong, for the reasons given (Output clips to terminal width; corruption appears on screens with no description Box).
• The lastOutputHeight vs outputHeight asymmetry in onRender is still real and still reproduces — a frame taller than the terminal gets painted with no clear when the previous frame was short. I just can't yet connect it to this bug, since it self-heals on the next frame.

What I have not been able to reproduce in isolation is the corruption itself. Things my harness does not do that the real run does, in rough order of how suspicious I find them:

1. An agent subprocess running concurrently. If anything writes to stdout/stderr or calls console.log during a render, Ink's patchConsole path does clear-then-static-then-rerender, which is the kind of thing that desynchronises cursor bookkeeping. My harness renders in isolation with nothing else writing.
2. ModalOverlay — every corrupted screenshot is either a modal or a screen shown while an agent was working. My harness renders a plain Box column.
3. Original terminal dimensions are unrecoverable — the window has been resized since. From an 86-character status line rendering unwrapped, it was at least ~88 columns during the run; it is 69x37 now.

If someone with the real harness can run a self-driving setup with an agent actively streaming output and watch the status line, I suspect that's where it'll show up. Happy to keep going if useful, but I didn't want a wrong reproduction sitting in the thread while I do.

[Ref34t]

Root cause identified & fixed

Root cause: Ink v6's buildLayout.js calls node.setWidth(measureText(text).width) on <Text> nodes, overriding the Yoga setMeasureFunc that would properly wrap text to the parent Box's width. For multi-line descriptions, measureText returns the full single-line width (e.g. 73 chars). Without a measure function, Yoga doesn't re-measure at the parent's width, so the text node reports its raw width. The parent Box then reports a layout wider than the Ink output buffer. When Ink writes past the buffer edge, the terminal wraps the text at the screen edge, misaligning Ink's cursor tracking for all subsequent rows — labels bleed into descriptions and the Confirm button overlaps the last description line.

Fix: Added prewrap() — a greedy word-wrap function that inserts \n at word boundaries at the description column width before passing text to <Text> (src/ui/tui/primitives/PickerMenu.tsx). This makes measureText return the correct multi-line height, so Yoga allocates the right vertical space and no overflow occurs.

The descriptionWidth() clamp (commit c9e5b87) is necessary but not sufficient — it limits the column width on narrow terminals, but on wide terminals it still returns 56, same as the original constant. The pre-wrapping is what actually prevents the overflow.

PR: #989 (draft)

Note: ink-testing-library@4.0.0 is incompatible with ink@6.8.0 — even <Box><Text>a</Text><Text>b</Text></Box> throws Text string "a" must be rendered inside <Text> component. All existing PickerMenu tests pass vacuously (they only check line widths; the error message happens to wrap to fit at narrow widths). This is a pre-existing infrastructure issue that blocks reliable rendering-level test assertions.

[Ref34t]

Retracting my previous comment. The "root cause identified & fixed" analysis above is wrong, and PR #989 is closed. Correcting it here so nobody builds on it.

What that comment claimed

That Ink v6's buildLayout.js calls node.setWidth(measureText(text).width) on <Text> nodes, overriding the Yoga measure function, so descriptions overflow their layout cell and the terminal wraps them.

Why it is wrong

1. build-layout.js is never loaded. It is CommonJS (require) inside an ESM package – ink@6.8.0 is "type": "module" with entry build/index.js. Nothing in the package imports it:

grep -rln "build-layout" node_modules/.../ink/build/   →  no results

2. The live path does the opposite. dom.js:17 installs a measure function on every text node:

if (nodeName === 'ink-text') {
    node.yogaNode?.setMeasureFunc(measureTextNode.bind(null, node));
}

and measureTextNode (dom.js:90) wraps to the container width:

if (dimensions.width <= width) return dimensions;
const wrappedText = wrapText(text, width, textWrap);
return measureText(wrappedText);

dom.js never calls setWidth on a text node. Yoga does re-measure at the parent width.

3. Ink clips to the terminal width, so the overflow is impossible.

• ink.js:242 — rootNode.yogaNode.setWidth(terminalWidth)
• renderer.js:23 — new Output({ width: node.yogaNode.getComputedWidth() })
• output.js:76 — for (let x = 0; x < this.width; x++), sliced with sliceAnsi

Ink cannot write past the screen edge, so the terminal's own line-wrapping cannot be the mechanism. This is the same reason #988 was withdrawn.

4. It does not match the screenshots. The corruption also appears on screens where the description Box never renders – the intro screen, status lines, and the label-only issue-tracker checklist. A PickerMenu description change cannot explain those.

Where this actually stands

Ruled out so far, each with a specific reason:

Theory	Ruled out because
Hardcoded description width (width={56})	The clamp returns 56 at any terminal ≥62 columns – a no-op at the width where this happened
Terminal resize mid-run	Real-terminal harness ran ~176 ticks at multiple widths with no corruption
Tall frame / frame taller than window	Reproduced an unrelated missing-clear, but it self-heals on the next frame
Text overflowing the Ink output buffer	Ink clips every line to the terminal width (above)

What is still solid is the original evidence: the overwrite is character-exact, which points at a stale-buffer or cursor-tracking problem rather than a layout one. Three cases, predicted vs observed, all exact matches:

new text	old text	result
Reading project context (23)	Checking Self-driving access (28)	Reading project contextccess
Enabling products (17)	Checking GitHub connection (26)	Enabling productsonnection
Designing custom scouts for this product (40)	Scout troop: 3 active (…); 25 disabled (82)	…productanalytics, revenue-analytics); 25 disabled

In every case the new line is written over the old one without the tail being cleared. That is a clearing/cursor bookkeeping failure, not a layout overflow.

The leading remaining suspect is concurrent writes to stdout during a render. The wizard runs an AI agent throughout, start-tui.ts calls render() with no options so patchConsole is at its default, and writeToStdout does log.clear() → write → restoreLastOutput(). If the intercepted output does not end in a newline, the restored frame resumes at a non-zero column. Every clean harness I built so far renders in isolation with nothing else writing, which is the single biggest difference from the failing run. I have not confirmed this, and I am not opening another PR until I can reproduce the symptom.

Leaving this open and unassigned in case someone with more Ink context sees it faster than I do.