The sandboxed XCTest runner can't write the start signal file to /tmp/.
Added --start-delay-ms to create-virtual-display.m as alternative to
--start-path. CI uses 10s delay so the test captures baseline render
stats before churn begins. Test skips start signal write when
pre-launched.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
The XCTest runner is sandboxed, causing Process-spawned apps to
inherit sandbox restrictions. The CI step now:
1. Builds for testing first (separate step)
2. Launches display helper and app from the shell (non-sandboxed)
3. Waits for app diagnostics and render stats
4. Writes manifests for the test to find the pre-launched state
5. Runs test-without-building
The test detects the pre-launch manifest and skips its own app launch.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Two fixes:
1. Use FileManager.temporaryDirectory for diagnostics path instead of
hardcoded /tmp/ — Process-spawned app inherits the test runner's
sandbox and can't write to /tmp/.
2. Add orderFrontRegardless() after activate() in the UI test window
creation path — on headless CI runners, activate() silently fails
and windows stay invisible, preventing terminal rendering.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
The Process-spawned app inherits the test runner's sandbox. Previous
attempts failed because diagnostics used hardcoded /tmp/ which the
sandboxed app can't write to. Now using FileManager.temporaryDirectory
for all temp paths (resolves to the sandbox container's tmp), and
inheriting the full test runner environment so the child shares the
same sandbox context.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Root cause: Process inherits the XCTest runner's sandbox, preventing
the app from writing diagnostics to /tmp/. NSWorkspace.openApplication
goes through LaunchServices, which launches the app in its own process
context outside the sandbox. Using activates=false avoids the 60s
foreground activation timeout that killed the previous NSWorkspace
attempt on headless CI runners.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Include the app's stdout/stderr log contents and full env dump in the
error message so we can see what happens on CI when the app runs but
doesn't write diagnostics.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
The test runner's environment contains XCTest variables
(DYLD_INSERT_LIBRARIES, XCInjectBundle, etc.) that cause the app to
hang when inherited by a Process-launched binary. Pass only system
essentials + our CMUX_UI_TEST_* vars, matching how the smoke test
launches the app with a clean environment.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
The smoke test (smoke-test-ci.sh) passes on the same WarpBuild runners
because it launches the binary directly. XCUIApplication.launch() and
NSWorkspace.openApplication both require foreground activation which
fails on headless CI runners since ~04:00 UTC 2026-03-23. Running the
binary directly via Process works without WindowServer activation.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
XCUIApplication.launch() hard-fails with a 60-second timeout when
it can't foreground the app on headless CI runners. This test never
uses XCUIApplication for interaction (no taps/keys) — it only reads
a diagnostics file.
Replace with NSWorkspace.openApplication which launches through
Launch Services, passes env vars via OpenConfiguration, and returns
immediately without blocking on activation failure.
Also add CI retry loop since runner environment is flaky.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Reverts cbb21872, 54ec524a, 10fd323b, 75375ab7, 82a16aa7 — all
attempts to fix display resolution UI test foreground activation
on CI that introduced regressions. Restores the state from the
last fully green CI run (56a4d258).
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
XCUIApplication.launch() blocks for 60 seconds trying to foreground
the app on headless CI runners, then hard-fails the test (not
recoverable with continueAfterFailure). This test doesn't need
XCUIApplication — it never taps buttons or types keys, it only reads
a diagnostics file.
Switch to NSWorkspace.openApplication which:
- Launches through Launch Services (proper macOS app lifecycle)
- Passes environment vars via OpenConfiguration
- Returns immediately with NSRunningApplication handle
- Doesn't block or hard-fail on activation issues
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
XCUIApplication.launch() fails to activate the app on headless CI
runners, reporting "Failed to activate application (current state:
Running Background)". With continueAfterFailure=false, this kills the
test before ensureForegroundAfterLaunch can retry.
Fix by temporarily setting continueAfterFailure=true around launch(),
then retrying activation via app.activate(). Also add a retry loop in
the CI workflow since foreground activation is inherently flaky on
headless runners.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Double-clicking to select text in the terminal was causing unwanted cursor
movement because the mouse position was being updated on both the first and
second clicks. This disrupted the selection gesture and caused the cursor to
jump to a different position than intended.
Fix by only updating the mouse position on the first click (clickCount == 1),
allowing the terminal's selection logic to handle multi-click gestures without
cursor interference.
Fixesmanaflow-ai/cmux#1698
Co-authored-by: BillionClaw <267901332+BillionClaw@users.noreply.github.com>
When a pane split occurs, SwiftUI recreates host views and the portal
system rebinds the WKWebView to a new container. However, the bind path
never called BrowserWindowPortalRegistry.refresh(), so WebKit's internal
rendering state (_exitInWindow/_enterInWindow) was never cycled. This
left the WKWebView frozen in the original pane after a split.
Add refresh() calls after every portal bind that changes the host, in
three code paths: the main update path (shouldBindNow), onDidMoveToWindow,
and onGeometryChanged. The refresh is a no-op when no reattach is needed
(browserPortalNeedsRenderingStateReattach == false), so normal rendering
is unaffected.
Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Use charactersIgnoringModifiers instead of characters when redispatching
Cmd-modified key events in performKeyEquivalent. Cmd-modified keys don't
produce text characters, so event.characters returns an empty string for
Cmd+Shift combos, preventing Ghostty from encoding them as kitty protocol
sequences. charactersIgnoringModifiers returns the actual key character
(e.g. "k" for Cmd+Shift+K) while modifiers are preserved in modifierFlags.
Fixes#1718
Co-authored-by: CHE-3 <schumannzheng@gmail.com>
Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
The `shouldConsumeSuppressedEscape` function had an early return that
unconditionally consumed all repeated Escape key events (`isARepeat`),
regardless of whether the suppression window had expired. This caused
Escape presses to be swallowed in TUI apps (e.g. lazygit) running in
panels, because the repeat events never reached the active responder.
Removing the `isARepeat` guard lets repeated Escapes fall through to
the existing time-based check (0.35s window), which correctly expires
and stops consuming events after the command palette is dismissed.
Fixes#1610
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
* Allow customizing numbered workspace and surface shortcuts
* Update bonsplit submodule to squashed main commit
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>
Publishing changes from background threads is not allowed in macOS 26
(Tahoe). Ghostty action callbacks run on I/O threads but were modifying
AppKit view properties and posting notifications without dispatching to
the main thread.
Fixes:
- GHOSTTY_ACTION_SCROLLBAR: wrap in DispatchQueue.main.async
- GHOSTTY_ACTION_CELL_SIZE: wrap in DispatchQueue.main.async
- GHOSTTY_ACTION_COLOR_CHANGE: wrap background color updates in main async
- GHOSTTY_ACTION_CONFIG_CHANGE: wrap background color clear in main async
- Add hasLiveSurface guard in TabManager.inheritedTerminalConfigForNewWorkspace
to protect the cmuxInheritedSurfaceConfig call site missed in the initial fix
- Expand malloc_size comment to clarify it is a best-effort heuristic, not a
lifetime guarantee (per Copilot review)
ghostty_surface_quicklook_font returns an unretained CTFont pointer that
can become stale on Intel Macs, leading to EXC_BAD_ACCESS (SIGSEGV) when
creating a split. This is a follow-up to the same crash pattern fixed in
#1496.
Add malloc_size validation in cmuxCurrentSurfaceFontSizePoints to detect
freed heap allocations before interpreting the pointer as a CTFont. Also
add hasLiveSurface guards in inheritedTerminalConfig and
rememberTerminalConfigInheritanceSource to skip surfaces whose native
state is closing or closed. All callers already handle nil gracefully by
falling back to inherited config values.
When a non-Latin input source like Korean 두벌식 is active,
event.charactersIgnoringModifiers returns Hangul characters (e.g. ㅅ
for T key) instead of Latin letters. This caused all character-based
shortcut matching to fail — Cmd+T, Cmd+D, Cmd+1-9, Ctrl+N/P, etc.
Root cause: KeyboardLayout.character(forKeyCode:modifierFlags:) assumed
CJK input sources lack kTISPropertyUnicodeKeyLayoutData, but Korean
두벌식 has it. UCKeyTranslate returned Korean characters and the ASCII
fallback was never reached.
Fix:
- KeyboardLayout.character(): check result is ASCII before accepting;
fall through to TISCopyCurrentASCIICapableKeyboardInputSource() when
the current source returns non-ASCII characters
- Add KeyboardLayout.normalizedCharacters(for:) helper that normalizes
event.charactersIgnoringModifiers for shortcut comparison
- Apply normalization in handleCustomShortcut (AppDelegate),
BrowserPanelView omnibar key handler, and BrowserPopupWindowController
Cmd+W handler
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
