wt switch picker panics with exit 101 when a diff preview exceeds 65,535 lines (skim total_lines is u16)

[sandertammesoo]

Summary

wt switch (interactive picker) panics and exits 101 a few seconds after it opens, whenever a branch's diff preview is longer than 65,535 lines.

thread 'main' panicked at .../skim-5.6.5/src/tui/preview.rs:229:56:
called `Result::unwrap()` on an `Err` value: TryFromIntError(PosOverflow)

The preview loads asynchronously, so the picker paints normally first and dies 3-5 seconds later. On screen the panic is overwritten by the shell prompt almost immediately, which makes it look like the picker just closes by itself. No diagnostic.md is written, because the process aborts rather than returning an error.

Cause

skim 5.6.5 stores the preview line count in a u16:

// skim/src/tui/preview.rs:229
self.total_lines = text.lines.len().try_into().unwrap();

Any preview over 65,535 lines panics. wt switch's diff preview passes the full git diff <default>...<branch> output, so this is reachable on any long-lived branch.

Reproduction

In a repo where a branch diffs more than 65,535 lines against the default branch:

$ wt switch          # picker opens, then dies ~3-5s later
$ echo $?
101

Line counts in the repo where I hit it:

branch	git diff master...<branch> lines	picker
A	126,021	panics
B	106,009	panics
C	99,758	panics

A second repo whose largest branch diff is 39,547 lines never panics — consistent with the 65,535 boundary.

Not a pager issue: --config-set 'switch.picker.pager = "cat"' panics identically, so it is the raw line count rather than anything delta emits.

Workaround

Capping the pager output keeps the picker alive (verified running 90+ seconds with previews rendering):

[switch.picker]
pager = "delta --paging=never | head -n 20000"

Possible fixes

• Truncate preview content in worktrunk before handing it to skim, so a large diff renders a capped preview instead of aborting the process.
• Upstream: skim could clamp or widen total_lines instead of unwrap()-ing the conversion. I found no existing issue for this in skim-rs/skim.

Environment

• worktrunk v0.75.0 (Homebrew bottle, which vendors skim 5.6.5)
• macOS 26.4, Apple Silicon
• zsh, TERM=xterm-256color, run inside a terminal multiplexer (herdr) under WezTerm

[worktrunk-bot]

Thanks for the report — the diagnosis is exactly right, and it reproduces: handing render_preview's output a 70,000-line body produces a 70,003-line pane, which is the count skim's u16 conversion panics on.

#3959 caps every preview body at 60,000 lines where they all converge before skim, and prints ○ Preview truncated to 60000 lines above the pane when one was cut. The cap sits under the 65,535 ceiling rather than at it — the same u16 bounds the pane's scroll offset, so lines past it can't be scrolled to anyway. That makes the pager = "… | head -n 20000" workaround unnecessary, and covers the panes that don't go through the pager at all (the comments thread, a --prs row's forge log).

Reporting it upstream is worth doing too — total_lines could clamp instead of unwrap()-ing — but that's a separate call for a maintainer, who will also review the fix here.