XCUITest launches the app as a separate process that doesn't inherit
XCTest env vars (XCTestConfigurationFilePath, etc.), so
isRunningUnderXCTest() returns false. The app then hits
shouldBlockUntaggedDebugLaunch() and exits with code 64, causing the
test runner to hang waiting for the app to launch.
Fix: detect CMUX_UI_TEST_* env vars set via XCUIApplication.launchEnvironment
and skip the launch guard. Also revert the failed CMUX_TAG ci.yml workaround.
Debug builds refuse to launch without CMUX_TAG to prevent accidental
untagged launches. XCUITest launches the app as a separate process
without XCTest env vars, so the app's isRunningUnderXCTest() check
fails and the app calls exit(64). The test runner then waits forever
for the app to report back. Set CMUX_TAG=ci in the CI env.
The Mac Mini runner has no dev certificates, so xcodebuild produces
an ad-hoc signed app. Gatekeeper rejects it, causing XCUITest to hang
forever at app.launch(). Split build and test phases, strip the ad-hoc
signature between them so the app can launch.
Org policy now requires actions pinned to immutable SHAs instead of
mutable version tags. Pin actions/checkout, actions/github-script,
softprops/action-gh-release, and oven-sh/setup-bun across all workflows.
Remove -Dxcframework-target=native from CI and release workflows,
defaulting to universal (matching upstream ghostty). The native target
produces a macos-arm64 xcframework slice that causes Xcode to link the
final binary differently (~70KB more __text), resulting in menubar and
right-click lag on M1 Max. The arm64 static libraries are byte-for-byte
identical between native and universal builds - the difference is purely
in how Xcode resolves the xcframework slice.
The -Dxcframework-target flag controls platform slices (native=macOS
only, universal=macOS+iOS), not CPU microarchitecture. Removing it
caused CI to attempt iOS builds which fail due to missing Metal
iOS toolchain on the runner.
* Fix zsh git branch refresh race after cwd change
* Clarify intentional duplicate cwd check in git refresh path
* Add Metal Toolchain download step to CI and release workflows
Fixes build failure when compiling Metal shaders for iOS xcframework
targets — the self-hosted runner needs `xcodebuild -downloadComponent
MetalToolchain` installed before `xcrun metal` can run.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>
The self-hosted runner (M4 Mac Mini) was building GhosttyKit with
-Dxcframework-target=native, producing M4-tuned binaries. This caused
menubar and right-click lag on M1 machines. Dropping the flag defaults
to universal, which works well across all Apple Silicon chips.
Add "Failed to activate application" to the retry/skip patterns so
the self-hosted runner gracefully skips UI tests when the app can't
come to foreground (Running Background state).
- CI: replace Node/npm with Bun
- Add view-transition animations for theme toggle
- Set html background for flash-free theme switches
- UI refinements to download button, brew command, and layout
- Replace package-lock.json with bun.lock
- Minimal centered layout with Geist sans font
- Typing animation cycling through agent names
- Light/dark mode toggle via next-themes
- Download for Mac button linking to latest DMG
- Feature list, GitHub + Docs footer links
- Meta tags and Open Graph for SEO
- CI: add web typecheck job (tsc --noEmit)
* Fix zsh ZDOTDIR wrapper + log parsing with -- messages
* Fix CI race condition: serialize self-hosted builds with concurrency group
Two workflows racing on the same self-hosted runner caused DerivedData
corruption (release's rm -rf nuked DerivedData while CI was building).
Add shared concurrency group and scope DerivedData cleanup to project.
Add a step to remove stale GhosttyTabs DerivedData before building
to prevent the "cannot open constant extraction protocol list input
file" error that occurs with incremental builds on self-hosted runners.
