Truecolor terminal backend (x/vt) + mouse support, rebased onto config/keymap + resizable panes

[citizen-123]

This carries the work from #3 (by @cameronsjo) forward onto the current main, which has since landed the config-driven keymap, resizable panes, repeater, and CI. I re-integrated the changes on top of that architecture rather than asking for another round of rebasing, and resolved the conflicts and the geometry interaction myself. Opening it as a separate PR so #3's history and authorship stay intact.

What's kept from #3

• Terminal backend swap — hinshun/vt10x → charmbracelet/x/vt. This is the headline. vt10x is unmaintained and packs 24-bit truecolor into the same integer space as 256-color palette indices, so truecolor targets silently lost color. x/vt keeps a real color.Color per cell, so Render walks CellAt and uses Style.Diff to emit only the SGR delta between adjacent cells. x/vt's Read is pull-based, so NewVT runs a reply-pump goroutine that Close stops cleanly.
• Mouse support in the split panes: clicks move focus and select flows (clicking the already-selected row opens it), the wheel scrolls the traffic list or pages the hosted app, and events reach the child through a neutral terminal.MouseEvent so internal/tui never imports x/vt and internal/terminal never imports bubbletea.
• Detail view expands embedded JSON / escaped-newline strings, capped in depth, and clearly marked so decoded content is never confused with what was on the wire.
• Security hardening: capture/export files are 0600, the config dir is forced to 0700, and the log file is opened after the config dir exists.

What I changed to fit main

• Dropped the branch's -leader flag and leader.go. main already makes the leader configurable through its keymap config (cfg.Keys.Leader), so a parallel CLI mechanism would just be a competing duplicate. The runtime mouse-capture toggle is now a first-class keymap action (ActMouseCapture, default leader m), so it's rebindable and shows up in the generated help overlay automatically.
• Mouse hit-testing now derives pane geometry from main's splitRatio via a shared paneBoxWidths, so clicks track the resizable divider instead of a fixed 50/50 split.
• Carried Swap vt10x for charmbracelet/x/vt, add mouse support to the split-pane TUI #3's pane-overflow fix onto the resizable geometry. lipgloss draws a border column on both sides of both panes — four columns, not two — so main's leftPaneWidth + rightPaneWidth == width - 2 actually rendered a row width + 2 wide (verified: at width 80 the joined row is 82 cells), wrapping every pane line and pushing mouse rows off. The pane boxes now sum to exactly the terminal width; resize_test is updated to the corrected invariant, and there's a test that measures the rendered row width against the terminal width.
• renderTraffic's row accounting (shared with mouse hit-testing via trafficRowLayout) now also reserves main's : command-line row, so a click still lands on the row drawn when the vim command line is open.

go build, go vet, and go test ./... all pass.

Known issue: go test -race is red (upstream, in x/vt)

The CI -race job will fail, in internal/terminal only — every other package is race-clean. The race is entirely upstream: x/vt's Emulator.Close() writes an unsynchronized closed field that Emulator.Read() reads. It is reachable by design, not misuse — Close() is the only way to interrupt a blocked Read(), so any correct shutdown of the reply pump touches it.

I traced the x/vt source to confirm it can't be worked around from here: replies only drain through the racy Read, Close is the only way to unblock it, and the closed field is internal, so no wrapper-side lock can cover it. The newest x/vt pseudo-version (…20260727…) still has the bug. The fix is a one-line atomic.Bool in charmbracelet/x/vt.

Three ways to green CI, for whoever merges to decide:

1. Land the upstream fix and pin past it (correct, my recommendation).
2. Skip the three shutdown tests under -race with a build tag and a comment linking the upstream issue (keeps normal go test coverage; loses -race coverage of the Close path).
3. replace to a forked x/vt with the fix (heavier; adds a fork to the dependency tree).

I can apply (2) on request. I'll file the upstream issue and link it here.

---

Generated by Claude Code

[cameronsjo]

Thanks for carrying the twelve commits forward rather than sending #3 back for another rebase — and for the write access. I took you up on the "have a look" by fixing my own carried-forward bugs directly on this branch rather than stacking a PR in front of your merge. Six commits; here's each one, and the two judgment calls worth disagreeing with.

tui: gate mouse input on the modal states, and scroll the editor with the wheel — closes findings 1 and 2 from your review of #3, which were both still live here. Update dispatched tea.MouseMsg straight to the panes without consulting a single modal flag, so a click behind an overlay moved the flow selection or reached the child under a screen showing neither pane. Rather than three scattered guards, there is now one gate at the top of onMouse that mirrors the precedence your tea.KeyMsg branch already establishes. It splits the states on what View() actually draws: showHelp and repeating paint over the whole screen, so they are handled before any hit-testing; editing and viewing replace only the right pane's content, so they stay pane-local in onRightPaneMouse and the terminal pane keeps taking clicks. Finding 2 was the same bug one level down — the click path guarded m.editing || m.viewing while the wheel path guarded only m.viewing. It routes rather than swallows: the help overlay scrolls on the wheel with the same clamp onHelpKey applies to j/k, and the editor scrolls too.

Two things there you may want to push back on. First, filtering and cmdline swallow clicks on both panes, not just the traffic list. That mirrors the keyboard exactly — no keystroke reaches the terminal pane while a text input is focused, since onFilterKey and onCmdKey sit above onKey — but it does mean you cannot click into the terminal with the : line open. Consistent, and arguably over-broad; easy to narrow if you would rather the left pane stayed live. Second, repeating is not one of your review findings — I added it because View() returns repeaterView() over the whole screen, so clicks were landing on panes that weren't drawn. Same bug, but it is scope I added rather than scope you asked for.

One implementation note, since it looks like a mistake otherwise: the editor takes the wheel as up/down keypresses rather than the tea.MouseMsg itself. bubbles' textarea has no mouse handling at all — unlike viewport, which is why the detail view can forward the message verbatim — so forwarding it would compile, run, and scroll nothing. This is the move wheelPageKey already makes on the terminal pane, where a notch becomes PgUp/PgDn.

terminal: bound VT.Close so a stalled child can't wedge the quit path — finding 4. Close waited on v.done unconditionally, and term.Close only reaches one of the two places pumpReplies parks. Unblocking a pump sitting in Read is what it is for; a pump sitting in resp.Write, where it goes once a stalled child stops draining its pty, is not reachable from Close at all — so a wedged child made quitting wedge too, taking away the last way out of an unresponsive target. The wait now has a ceiling and the pump is abandoned past it, since it is blocked writing to a descriptor the process is about to drop. I tried the cause-level fix first: darwin rejects SetWriteDeadline on a pty master outright ("file type does not support deadline"), verified against a writer demonstrably parked on a full pty, so there is nothing to set. Two tests cover the two branches of the select.

(Finding 3 — -leader=ctrl+i / ctrl+m breaking Tab and Enter — was already fixed on main; leader.go is gone and NewKeyMap rejects both.)

ci: quarantine the emulator-shutdown tests from -race, and run both test modes — this is why build-test was red, and the cause is not in this repo. charmbracelet/x/vt's Emulator.closed is a plain bool that Close writes while a parked Read reads it, unsynchronized. Read blocks on an empty pipe and Close is the only thing that unblocks it, so no shutdown can be written that the detector accepts, and SafeEmulator does not help — its Read takes no lock and it does not override Close. The five tests that call VT.Close move behind a //go:build !race tag. Note this also adds a plain go test ./... step to CI, because the workflow only ran the race job — without it the build tag would not have relocated those tests, it would have deleted them from CI entirely. Tracked upstream as charmbracelet/x#879 with a fix already proposed in charmbracelet/x#881; I verified that applying that patch locally turns this repo's whole suite green under -race with no exclusions at all, which is the evidence the exclusion is covering someone else's bug and not one of ours. That commit is the one to revert when #881 merges, and the file header says so.

Three follow-ups from a pre-PR pass over my own diff, all small: the editor wheel batched three cursor-blink timers where one will do; the help-scroll clamp was duplicated between the key and wheel paths, which is the exact drift this change exists to prevent, so both now share one clampHelpScroll; and two test traps — a nil *fakeEmulator stored into an interface field made m.screen == nil false, which would have panicked the first test to reach the left pane, and a clamp test that passed for free on any terminal tall enough to fit the help body.

go build, go vet, go test and go test -race all clean locally. Merge is yours to call, as you asked — flagging the two judgment calls above in case either is not what you want.

[cameronsjo]

Approving the reconciliation. I checked the merge (9ac5ad4, first parent 2941f9d = the #3 tip, second fa37bfa = main) headline by headline against what #3 carried, and nothing was dropped:

• the hinshun/vt10x → charmbracelet/x/vt swap, with truecolor SGR emission surviving into the pane (vt_color_test.go still covers the near-black case the old packed-uint32 path could not represent)
• mouse click, focus and wheel handling, and the SGR encoder tests
• JSON detail expansion
• the 0600 session file and the 0700 CA-directory Chmod in internal/proxy/ca/ca.go — both intact, including the MkdirAll-does-not-narrow-an-existing-dir case

The two places you reworked it are improvements rather than losses. paneRects now derives from paneBoxWidths instead of carrying its own m.width / 2 split, so hit-testing follows the divider wherever it is dragged — the resizable-pane work would have broken the old version outright. And threading cmdline through trafficRowLayout / flowRowIndex keeps a click mapping to the row actually drawn now that the : line takes a row; missing that would have put every click one row off whenever the command line was open.

Approving on the reconciliation and on the four commits I pushed to this branch. The merge itself stays your call.