On WarpBuild runners without a GUI session, XCUIApplication.launch()
blocks ~60s then fails with "Failed to activate application (current
state: Running Background)". Wrap launch() in XCTExpectFailure so the
test can continue — keyboard and element APIs work via accessibility
even when the app is in .runningBackground.
Increase test execution time allowance from 120s to 180s to account
for the 60s activation timeout on headless runners.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
The CI display helper now uses --start-delay-ms instead of --start-path
because the XCTest sandbox prevents writing to /tmp/. The harness manifest
no longer includes startPath, but the test guard still required it, causing
"Incomplete external display harness configuration" errors.
Make startPath optional in both the manifest and environment variable
harness loading paths, and gate the start signal write on displayStartPath
being non-empty.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
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>
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>
* Show update-available banner automatically on launch
Probe for updates immediately on launch via Sparkle's
checkForUpdateInformation() so the sidebar surfaces a passive update
indicator without waiting for the 24h scheduler. When Sparkle detects
an available update in the background, the pill now shows
"Update Available: X.Y.Z" with accent styling while the updater is
idle. Clicking it triggers the full interactive update flow.
Also fixes thread safety in delegate callbacks by dispatching
@Published mutations to the main queue.
Closes#1643
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
* Add periodic background update probe every 15 minutes
The launch-only probe wouldn't catch updates published while the app
is already running. Add a repeating 15-minute timer that calls
checkForUpdateInformation() so the sidebar banner appears within a
reasonable window after a new version is published.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
* Change background update probe interval to 30 minutes
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
* Change update check interval to 1 hour and migrate existing users
Reduce Sparkle's scheduled check interval from 24h to 1h so update
banners appear sooner. Migrate users stuck on the old 24h default by
bumping the migration key to v2. Align background probe interval with
the Sparkle check interval instead of hardcoding 30 minutes.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>
