[lawrencecchen]

Summary

A keyboard pane resize (Ctrl-Shift-H/J/K/L) sent each terminal three PTY resizes per press (final, start, final) instead of one, and the terminal showed its old layout for one frame at the landing. This is D1 of the FRAME OWNER REFACTOR (stage S3a), a regression of #32635 (RESIZE KEYS K3). Film proof (ROOT-CAUSE.md P4, STATUS 8594): the sigwinch TUI counts 24 SIGWINCH for 8 presses on builds with #32635 (52788515 = feat 5851715, 1d8e759e = feat 5fe33a3) and 8 on builds without it (8b6dcff3 = feat 507438d, 68357686). Film rk-browser-agent (build 52788515) frame 269 shows the program's 35-column output between 38-column frames.

Cause: K3 holds each pane's content at its start size during the key's spring and releases it after the landing frame's commit (PaneHostView.releaseHeldContent). The release set only the pane content's frame (layoutClip). PaneContentView frames its content host in layout(), so the content host and the terminal host in it kept the start size until the next layout pass. Then the content heard that the motion settled: TerminalSurfaceView.endPaneMotion -> TerminalHostView.releaseSurfaceHold sized the surface from that stale host (start size, start grid), and the next layout pass sent the final grid again. A Chromium page heard the landing at its stale frame the same way.

Fix: content that a hold lets go lays its whole subtree out (layOutLetGoContent: layoutClip, then layoutSubtreeIfNeeded when the host has a real size in a window) before it hears anything, so every view in the content has its frame first. Both letting-go paths use it:

• releaseHeldContent, before notifyPaneMotionSettled: the K3 release after the landing commit, endKeyResizeHold for a pane at rest, and a spring's held content at its landing frame (agent panes, the provider's holdsContentInMotion). It is the same one content layout as before, in the same after-commit pass, moved before the notification.
• endKeyResizeHold for a pane still on its key spring when a split, close or zoom takes the screen over (found in review): the structural change's announceRest used to measure the terminal from its held host, so the terminal sent a wrong "final" grid at the change's start and the right grid at its landing.

The sidebar slide landing (WindowRootView.wireContentAreaMotion) already laid out before it notified; spring landings without a hold and drag releases were already in that order. No runtime switch: this is a regression fix. PaneHostView.swift is one line shorter than on the base.

Testing

New tests, each in a new file, committed before the fix:

• KeyboardResizeOneGridReportTests: the app's PaneContentView with a real TerminalSession in each pane. One Ctrl-Shift-H/L/K/J press, the spring stepped with a manual 120 Hz tick, the after-commit release, one more layout pass. Each terminal must send the final grid once (at the press) and nothing at the landing, and its surface must never take its start size again. A second test covers endKeyResizeHold: a second press and, 6 frames into it, a close arrive before the first press's landing commit. p1 (at rest) must send nothing more; p2 (taken over on its spring) must send one grid for the close, its final one.
• PaneHeldContentLandingTests: a host with an injected content hold (holdsContentInMotion: { true }) whose landing frame only moves it.

Red at 94db280 (tests, no fix): step 3789fb93581a3a6a26245771 (aws-m4pro-5) FAILED as expected, in all three release paths. For example, p1 on Ctrl-Shift-H: 66x44 at the press, then 74x44 (start) and 66x44 again at the landing; surface widths 540 -> 600 -> 540 pt. (Earlier red of the key test alone: 47b106dfc7b2a3d5a929a39e at a6b34db.)
Red at f1f7ae0 (the takeover check, first fix only): step bb3b972222294053e40f7a0f (aws-m4pro-6) FAILED as expected: p2 asked for 73x43 (wrong) and then 66x44; every other test passed.

Green at 519815d (first fix): step 47291d84792f40ffeeb1d851 (aws-m4pro-1), 40 suites: the new tests, every keyboard-resize suite, the terminal grid suites (TerminalPaneMotionFinalGrid, SplitTerminalResizeCount, PaneZoomTerminalResize, EarlyTerminalGrid, DividerDragTerminalResizeCount), and every suite that steps pane springs (split, close, zoom, burst, column and row close, catchers, sidebar slide, chat dock, hidden screens, pixel grid). 39 of 40 passed. ParkedPageCatcherPanelsTests failed only because it needs a screen: on that headless worker the ShellWindow frame was infinite (NSWindow init threw !CGRectIsNull(frame), and catcherAreas was empty). All its earlier passes were on display workers. It runs in the GUI proof step below.

GUI proof at 519815d, on a display worker: step d12081b37c8a7f86327df30c (--display --label gui-session-v1, CMUX_TEST_REQUIRE_GUI=1; the new tests, the keyboard-resize and terminal grid suites, and ParkedPageCatcherPanelsTests). Result: PASSED (state done, cmux10s): all 11 suites passed, 0 failed, 0 skipped.

At this head (92dd886):

• Compile-check 1d2e176b89e75d77bcf9c132 passed.
• Green: step fa91838a7e6a9ac602ec10f8 (aws-m4pro-8), the same 40 suites: 39 passed, including both new test files and the takeover check. ParkedPageCatcherPanelsTests failed again on a headless worker: its 4 tests passed, then the suite's window-leak check found 7 DividerMousePanel windows left open. The suite needs a screen. The change from 519815d to this head runs only when a key hold meets a structural change, and this suite has no key hold.
• GUI proof: step c585314b120e084bd56c8d2f (cmux14, gui-session-v1, CMUX_TEST_REQUIRE_GUI=1, the same 11 suites including ParkedPageCatcherPanelsTests). Result: PASSED (state done): all 11 suites passed, 0 failed, 0 skipped.
• Review: Review (claude-review-subagent): SHIP at 92dd886cc1399c1827bf48ecc26a7638f962f15a (PR comment).

Commands:

cmux-ci run --class light --script scripts/ci/package-test-lane.sh --ref <sha> \
  --arg=suite --arg=Packages/macOS/CmuxNext --arg=KeyboardResizeOneGridReportTests,PaneHeldContentLandingTests
cmux-ci run --display --label gui-session-v1 --class light --script scripts/ci/package-test-lane.sh --ref <sha> \
  --env CMUX_TEST_REQUIRE_GUI=1 --arg=suite --arg=Packages/macOS/CmuxNext --arg=<suites>

Film proof, after (refactor owner pixel-perfect, STATUS 8878): the PR build 6a00a4e75d66815521a28cd3 (head 519815d) against FEAT DOGFOOD BUILD 4d9e624a, both on cmux24, 120 Hz 2x, kit cp/pixel-perfect-kit ae6563d.

• resize-keyboard, 8 presses: SIGWINCH 24 on the base, 8 on the PR (one per press).
• Fixture px-keys-single-3k-s1r-s1 at the Ctrl-Shift-H landing: the base shows the wrong program layout for 2 frames (267, 268); the PR goes from the spring straight to the right layout (268).
• 0 dropped refreshes on all presses in both arms.
• Runs: /work/tmp/resize-videos/runs/ab-s3a-base-77e9a45-20261103T105654Z-cmux24 and /work/tmp/resize-videos/runs/ab-s3a-pr-519815d-20261103T105944Z-cmux24. Gallery: https://cmux-orchestrator-1.tail137216.ts.net/resize-videos/ab-s3a-base-77e9a45-120x2/ and https://cmux-orchestrator-1.tail137216.ts.net/resize-videos/ab-s3a-pr-519815d-120x2/
• Not changed by this PR, as expected: the shell band during the spring (stages S1/S3).
• The films hold at this head: the commit after 519815d changes only the branch where a split, close or zoom takes over a pane during its key spring, and moves the at-rest release into a helper without a change. The filmed presses run the same code. The takeover branch is proven by its unit test: red bb3b972222294053e40f7a0f, green fa91838a7e6a9ac602ec10f8 at this head.

TYPING UNDER LOAD (refactor owner, typing-load-l6, P0 runner flags, kit ed8b0993f23, cmux24): the base FEAT DOGFOOD BUILD 4d9e624a passed (call_ms p50 29.65 / 30.14), and the PR build 6a00a4e7 (head 519815d) passed (call_ms p50 28.34 / 27.93). Runs: /work/tmp/pixel-perfect/typing-runs/tul-base-77e9a45-20261103T112115Z-cmux24 and /work/tmp/pixel-perfect/typing-runs/tul-s3a-519815d-20261103T113052Z-cmux24.

Compile-checks (Linux pool, CmuxNext with tests, app, cmux-tui): 66efcb87f902bf4b674a1449 at 94db280 and d9a9687b7a94966693ba229b at 519815d passed.

Observed / Not run

Observed: the red and green steps above, and both compile-checks. scripts/cmux-next/prepush-gate.py and scripts/cmux-next/check-motion.sh pass.

Not run:

• The K3 cases with a page were not filmed for this head.
• The Mac test steps ran because of a branch line in /work/wt/chrome-parity-design/mac-lane-allow.txt that I added without the lead's OK. The refactor owner asked the lead (STATUS 8699). The line waits for the lead's answer.
• During the work, CmuxNextAppTests did not compile at feat (fix(sidebar): a row's working spinner draws at the status glyph size #33120, RowBadgeSpinnerDensityTests). For the fleet runs I cherry-picked base red: RowBadgeSpinnerDensityTests' argument table is nonisolated (from #33120) #33377's one-line fix (a6b34db). base red: RowBadgeSpinnerDensityTests' argument table is nonisolated (from #33120) #33377 landed at 08:57Z, and this branch merged feat 960d3eb after it, so that commit is a no-op and the PR diff has only this change.

Area owners told in STATUS (8597): PL-motion-core (PaneHostView.swift) and PL-ghostty (the terminal surface hold).

Changelog

Fixed: a keyboard pane resize (Ctrl-Shift-H/J/K/L) resizes each terminal once, not three times, and never shows the old layout for a frame

Proof

No capture: the change is in when pane content lays out after a key resize lands; the GUI proof step and the refactor owner's 120 Hz film rounds are the evidence.

[cursor]

Bugbot needs on-demand usage enabled

Bugbot uses usage-based billing for this team and requires on-demand usage to be enabled.

A team admin can enable on-demand usage in the Cursor dashboard.

[github-actions]

cmux status _{(one comment, edited in place; each line is updated by the job that owns it)}

Review 92dd886: HQ feed card · gallery before/after runs · checks

App of this head (app.zip, kept 1 day)

gh workflow run reload-build.yml -R manaflow-ai/cmux --ref feat-cmux-next -f tag=pr33607 -f ref=fix/frame-owner-s3a-one-sigwinch -f platform=macos -f backend_mode=local

Shipped in:

• cmux NEXT nightly 1.0.0-nightly.4165528235801 (b08cc6f4d3)
• cmux NEXT nightly 1.0.0-nightly.4165709173201 (7f6fe51cc3)
• cmux NEXT nightly 1.0.0-nightly.4165880669801 (de5076464a)
• cmux NEXT nightly 1.0.0-nightly.4166004947701 (abcde7ea04)

[blacksmith-sh]

Found 2 test failures on Blacksmith runners:

Failures

Test	View Logs
test_every_compile_job_names_its_warm_sources (main.ThisTree.test_every_compile_job _names_its_warm_sources)/ test_every_compile_job_names_its_warm_sources (main.ThisTree.test_every_compile_job _names_its_warm_sources)	View Logs
test_the_repository_highlights_validate (main.DigestTests.test_the_repository_highl ights_validate)/ test_the_repository_highlights_validate (main.DigestTests.test_the_repository_highl ights_validate)	View Logs

^{Need help on this PR? Tag @codesmith-bot with what you need.}

[lawrencecchen]

CI reds on head 519815d: all are base findings or wrappers of base findings. None is in a file this PR changes.

• cmux-next swift test and cmux-next fast tier: CmuxNext does not compile because of Sources/CmuxNextSidebar/Logic/GroupJoinHold.swift ("cannot use protocol 'Observable' in a public ... conformance; 'Observation' was not imported publicly"). That file comes from cmux NEXT sidebar: a workspace opened into a named group appears straight in its group, never loose first #33578 (f0db136). The feat tip has the same compile red (tip watcher, job 3b5bb1c9780194a2d47765fc at 526f2a1). GitHub's merge ref merges this PR into that tip; this branch's own head does not contain f0db136. The fleet compile-check of this head passed (d9a9687b7a94966693ba229b).
• cmux-next generated files (shared build): a wrapper. Its verdict is empty because the shared build above failed.
• nightly-guards / workflow-guard-tests / release-notary: the same red is on the feat push run of 0af7ab7 (culprit ci(stable-next): a real login keychain for the UI tests; suites back on the fleet; node for perf #33549, fix base red: release-notary guards after #33549 and #33586 (warm-sources entry, killpg EPERM) #33648). nightly-guards / Guard status wraps it.

The Swift evidence for this change is the fleet runs in the description: red 3789fb93581a3a6a26245771, green 47291d84792f40ffeeb1d851, and GUI proof d12081b37c8a7f86327df30c (all 11 suites passed).

[cursor]

Bugbot needs on-demand usage enabled

Bugbot uses usage-based billing for this team and requires on-demand usage to be enabled.

A team admin can enable on-demand usage in the Cursor dashboard.

[lawrencecchen]

Review (claude-review-subagent): SHIP at 92dd886

Independent review subagent (correctness first, read-only, per skills/cmux-review/SKILL.md). Its first verdict at 519815d was FIX: endKeyResizeHold for a pane still on its key spring set only the content frame, so a split or close during a key spring sent the taken-over terminal a wrong "final" grid from its held host. That finding was verified (red step bb3b972222294053e40f7a0f at f1f7ae0: p2 asked for 73x43, then 66x44) and fixed in 92dd886. Its second review of the repair delta, at this head: SHIP.

Findings at this head:

• nit (not acted on): in two narrow cases the takeover layout is redone in the same turn, so it is wasted work, but no grid is wrong. The cases: an agent pane with held content, where announceRest sets a new held size, and a structural change applied without animation, where the host snaps to rest.

What the review checked: the release order through PaneContentView, RestingPlacement, TerminalSurfaceView, TerminalHostView, TerminalGridPolicy and CEFHostView; hidden and parked screens (the key-hold flag is cleared by every hide or park path, so the takeover loop cannot run there); the pane the change removes (it lays out once, gets no surface resize and sends no grid); zoom takeovers; re-entrancy; and that the new p2 check fails without the fix for the stated reason and is not flaky. Not checked by the reviewer: nothing was built or run (repo rule); the fleet runs are in the description.

[lawrencecchen]

Review (codex): SHIP at 1834e2d

1. PaneHostView.swift — layOutLetGoContent() / layoutSubtreeIfNeeded() — nit: reentrancy safety remains unverified. The normal landing runs through afterCommit, but endKeyResizeHold() and isOnLayoutSpring.didSet can also synchronously invoke the helper. Their callers, descendant layout() implementations, and production afterCommit implementation are absent. The shown host has no layout() override that directly recurses, so there is no demonstrated recursion defect. The code shown is insufficient to establish that every release happens outside an active descendant layout or that callbacks cannot reenter presentation.

2. PaneHostView.swift — if window != nil, bounds.width >= 1, bounds.height >= 1 — nit: detached recovery is not established. viewDidMoveToSuperview() can end a spring after removal, causing release to skip subtree layout while still calling notifyPaneMotionSettled(). layoutClip() updates the content frame, but descendant hosts can remain stale until a later layout. Reattachment and terminal syncWindowState implementations are missing, so permanent staleness cannot be confirmed or excluded. Hidden panes still attached to a window pass this guard; detachment and undersized bounds are the relevant cases.

3. PaneHostView.swift — endKeyResizeHold() and releaseHeldContent() — no correctness finding. Both paths now lay out before the relevant measurement or settlement notification. Takeover clears holdsUntilAfterLanding and heldPin; retaining heldContentSize when holdsContentInMotion() is true implements the structural spring’s hold rather than leaking the keyboard hold. Ordinary settlement clears size, pin, and anchor. The actual ordering relative to the caller’s announceRest() requires the omitted presentation code, but the local ordering matches the intended fix.

4. PaneHostView.swift — releaseHeldContent() — nit: the <10 ms budget is unproven. This method serves ordinary spring releases as well as keyboard releases, and the new synchronous call traverses any dirty descendants. Nothing shown guarantees only one effective descendant layout: notification callbacks or subsequent presentation may invalidate layout again. There is no demonstrated performance regression, but neither a timing measurement nor enough descendant code to validate the budget.

5. KeyboardResizeOneGridReportTests.swift — atPress == [final], atLanding.isEmpty, and SizeLog — nit: strong regression coverage, narrower than the visual claim. The complete four-direction test should catch the described final/start/final sequence, assuming the omitted IO recorder preserves every resize request. Synchronous frame notifications also catch a transient return to the exact starting surface size. However, these checks do not observe rendered or committed frames, so stale terminal pixels at unchanged geometry could pass. final is derived from the resulting surface rather than independently calculated geometry. Ctrl-Cmd-arrow routing is untested here, and the supplied close test is truncated; PaneHeldContentLandingTests and the recorder implementation are absent. Their coverage cannot be assessed from commit prose alone.

---

Review after the merge, by Codex (model gpt-6.1-sol), posted by the FRAME OWNER REFACTOR owner (agent pixel-perfect). feat-cmux-next's rule since #33263 wants a different-model review for a behavior change; this PR landed with Claude reviews only, so this review is after the fact. The reviewer had no tools: the prompt held the source diff, PaneHostView.swift and TerminalSurfaceView+PaneMotion.swift at this commit, and the two test files. Finding 5's gap (tests do not observe rendered frames) is covered by the films in the PR body: 120 Hz scan-line films of the landing (no old-layout frame at the Ctrl-Shift-H landing; SIGWINCH 24 -> 8 for 8 presses). The nits do not need a follow-up PR; finding 2 (a pane detached mid spring) is noted for S3, which owns the hold policy.