[richiemcilroy]

A user on a 2020 Intel MacBook Pro with a Touch Bar (MacBookPro16,3, macOS 15.7.9) reported that the GPUI app (0.6.2-nightly.202610101017) crashed every time they started a recording, in every capture mode. The crash is an Objective-C exception that AppKit itself throws and then turns into a crash:

Exception Type:  EXC_BAD_INSTRUCTION (SIGILL)
Application Specific Backtrace 0:
  objc_exception_throw
  -[NSObject(NSKeyValueObserverRegistration) removeObserver:forKeyPath:context:]
  -[_NSTouchBarFinderObservation invalidate]
  ___NSTouchBarFinderSetNeedsUpdateOnMain_block_invoke_2
  NSDisplayCycleFlush
  CA::Transaction::commit()
Thread 0 Crashed:
  -[NSApplication _crashOnException:]

On Macs with a Touch Bar, AppKit's Touch Bar finder watches the key window's responder chain with key-value observing. Starting a recording hides and closes several windows at once (main window, target overlays), and when the finder rebuilds its observation during the next display-cycle flush, removing an old observer throws "Cannot remove an observer ... because it is not registered as an observer". AppKit catches that in its CATransaction commit handler and calls _crashOnException:. Cap never puts anything on the Touch Bar, and the exception is raised inside AppKit, so nothing in Cap's own code can catch it today.

Fix

• -[_NSTouchBarFinderObservation invalidate] is routed through a guard at startup (platform/macos_exception_guard.rs). The guard calls the original implementation and, if it throws, logs the exception's name and reason and returns.
• The @try/@catch is in a small Objective-C file, native/exception_guard.m, built by build.rs on macOS only. An Objective-C exception must not unwind through a Rust frame (Rust aborts), so the original method is called from Objective-C with no Rust frame between the throw and the catch. objc2's own catch would need its nightly-only unstable-c-unwind feature to be safe here.
• If AppKit ever drops the class or method, the guard logs that there is nothing to guard and installs nothing.

Dropping a failed teardown leaves at most one stale observation in AppKit's Touch Bar bookkeeping. Modern Foundation removes observers when the observed object is deallocated, and Cap shows nothing on the Touch Bar, so nothing user-visible depends on it.

Tests

• an_unbalanced_kvo_removal_throws_the_reported_exception reproduces the report's exception (removing a KVO observer that was never added) and checks the trampoline catches it with the same reason text.
• a_guarded_method_survives_the_exception_every_time installs the guard on a test class whose invalidate throws that exception, then calls it three times. Without the guard the test process aborts.
• appkit_still_has_the_touch_bar_finder_method_this_guards fails if a macOS update renames _NSTouchBarFinderObservation or invalidate, so the guard cannot silently stop applying.
• Launching the app logs guarded the Touch Bar finder's observation teardown on macOS 27 (Apple Silicon).

I could not reproduce the crash itself: this needs Touch Bar hardware. The fix does not depend on what triggers the exception, only on where AppKit throws it.

Confidence Score: 5/5

The PR appears safe to merge; no new actionable issues were found.

Summary

This PR catches the Touch Bar finder's teardown exception before it can crash the app.

• The GPUI app catches Touch Bar teardown exceptions before they crash it.

_{Reviews (4) · Last reviewed commit: "fix(desktop-gpui): count exception-guard..." · Reviewed by Greptile}

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated
cap-status	Ready	Preview	Oct 18, 2026 5:43pm UTC

[richiemcilroy]

@greptileai review

[richiemcilroy]

@greptileai review

[richiemcilroy]

@greptileai review

[capy-ai]

Capy found no issues.

View 1 other finding in Capy.