15 commits in 3 minutes 11 seconds, to fix a crash inside code we never wrote.

On April 28, 2026, the github.com/mediar-ai/fazm repo (an MIT-licensed Mac AI agent) recorded 18 public commits to main. Three of them, between 13:14:09 PT and 13:26:33 PT, taught the new pop-out chat shortcut to inherit the workspace of the currently focused pop-out instead of resetting to the global default. The other 15, between 14:17:16 PT and 14:20:27 PT, are the FAZM-20 mitigation: a 68-line Swift extension at Desktop/Sources/Extensions/NSWindow+CrashWorkarounds.swift, an app-global call from FazmApp.swift, and 12 per-window call sites. No new release tag was cut today; the four bullets are sitting in the unreleased array of CHANGELOG.json waiting for a 2.5.1 or 2.6.0 cut.

FAZM-20 is the internal ticket for an EXC_BAD_ACCESS crash whose stack trace ends in NSConcreteMapTable dealloc inside __NSTouchBarFinderSetNeedsUpdateOnMain_block_invoke_2. Translation: the macOS app crashed when the operating system was cleaning up a hash table that NSTouchBarFinder uses internally. Fazm has zero NSTouchBar code in the codebase. AppKit auto-creates a TouchBar object for every NSWindow regardless, and the auto-create path keeps weak references to views in an internal NSMapTable. Heavy window churn (floating bar plus pop-outs plus overlays plus toasts) appears to be triggering a weak-reference bookkeeping bug in that map table on dealloc. The header comment of the new extension file says verbatim: 'First seen 2026-03-29; 83 affected users in 30 days; still firing on 2.4.1.'

Because the user does not care whose bug it is. The crash signature is 100% AppKit, QuartzCore, and CoreFoundation frames; zero Fazm code. But the customer-visible result is the app dies. A consumer Mac AI agent that crashes once a session is unusable, and shipping a defensive workaround is faster than waiting for an OS-level fix from Apple. The mitigation is small and reversible: opt every window out of AppKit's auto-touch-bar machinery, disable window tabbing globally, and move on. If Apple ships a fix, the workaround can be deleted in one commit.

Clone github.com/mediar-ai/fazm and run: git log --pretty='%h %ci %s' --since='2026-04-28 14:17:00' --until='2026-04-28 14:21:00'. You should see exactly 15 lines, the first being cb379afb at 14:17:16 -0700 (Fix FAZM-20 TouchBar crash by applying global NSWindow workarounds) and the last being 131e3736 at 14:20:27 -0700 (Update changelog with fix for intermittent macOS crash). The new file Desktop/Sources/Extensions/NSWindow+CrashWorkarounds.swift was introduced by commit 08d15b64 at 14:18:04 PT and is 68 lines long. Every line below maps to a public commit hash you can read in under a minute.

Two things. First, applyAppGlobalCrashWorkarounds() is called once from FazmApp.swift at line 168. It sets NSWindow.allowsAutomaticWindowTabbing to false and NSApplication.shared.isAutomaticCustomizeTouchBarMenuItemEnabled to false. Then it registers a NotificationCenter observer on NSWindow.didBecomeKeyNotification and didBecomeMainNotification so any window that becomes visible (including SwiftUI-managed windows the app does not construct itself) gets its per-window mitigations applied. Second, applyCrashWorkarounds() is the per-window method. It sets self.tabbingMode = .disallowed and goes through KVC to set automaticallyCustomizesTouchBar to false. It is idempotent and safe to call multiple times.

Twelve explicit per-window call sites plus one app-global call. The 12 call sites are FloatingControlBarWindow.swift:104, DetachedChatWindow.swift:52, PaywallSheet.swift:488, ClaudeAuthSheet.swift:347, ToastManager.swift:41, SessionRecordingPermissionWindow.swift:221, BrowserExtensionSetup.swift:66, FeedbackView.swift:55, AnalysisOverlayWindow.swift:88, SilenceOverlayWindow.swift:52, PostOnboardingTutorial.swift:619, AppManagementSetup.swift:60. The app-global call is FazmApp.swift:168. SwiftUI windows the app does not construct itself are caught by the NotificationCenter observer registered inside applyAppGlobalCrashWorkarounds. The grep that confirms this is: grep -rn 'applyCrashWorkarounds()' Desktop/Sources/.

Yes, briefly. Commit cb379afb at 14:17:16 PT calls NSWindow.applyAppGlobalCrashWorkarounds() from FazmApp.swift. Commit 08d15b64 at 14:18:04 PT introduces Desktop/Sources/Extensions/NSWindow+CrashWorkarounds.swift, which contains the definition. Between those two commit timestamps (48 seconds), main would not compile in isolation. In practice the staged tree compiled cleanly because the file existed locally before the commits were ordered out, but anyone bisecting between cb379afb and 08d15b64 will hit a build failure. A cleaner ordering would have committed the extension file first; the actual ordering is what landed.

Defense in depth. The app-global path relies on a NotificationCenter observer, which only fires on didBecomeKeyNotification and didBecomeMainNotification. Some windows in the app (panels, transient overlays, child windows that do not become key) never receive those notifications, so the observer would never apply the per-window mitigation to them. The per-window calls cover those paths explicitly. They also document intent: when you read FloatingControlBarWindow.swift line 104 in isolation you can see what mitigation this window has and why, without having to know about a side effect attached to a global notification at app launch.

Indirectly. Fazm reads the focused window through the macOS accessibility tree (AXUIElement, kAXFocusedWindowAttribute, kAXChildrenAttribute) instead of through screenshots. That choice means the app spawns a lot of NSWindow and NSPanel instances of its own (a floating control bar, a chat pop-out, an analysis overlay, a silence overlay, a toast, a paywall sheet, a feedback window, several first-run windows). Each of those windows is a candidate for the FAZM-20 weak-ref crash. A screenshot-based agent would have a single full-screen overlay and possibly one chat window, which is a much smaller crash surface. The cost of choosing accessibility APIs is more native windows; the benefit is structural reads instead of pixel-level OCR.

Three commits between 13:14:09 PT and 13:26:33 PT changed how a new pop-out chat (Cmd-Shift-N) decides which workspace it belongs to. Before: the new pop-out always opened with the global default workspace. Issue: if you were in a chat about workspace A and pressed Cmd-Shift-N to start a fresh thread on the same project, the new window jumped to whatever the default was. After commit 504b7cf0 at 13:14:24 PT (12 lines added to FloatingControlBarWindow.swift), the new pop-out reads the current workspace of the focused pop-out and inherits it. Commit 1c329ac3 added 18 lines to DetachedChatWindow.swift to make detached chat windows accept an inherited workspace. Commit a559da32 at 13:26:33 PT added the unreleased changelog bullet. Three small commits, one customer-visible UX fix.

Yes. The four entries currently in the unreleased array of CHANGELOG.json (pop-out debounce, paywall stale-response, workspace inheritance, intermittent crash) will be the spine of the next tagged release. Whether that ends up as 2.5.1 (a patch line) or 2.6.0 (a minor) depends on whether anything else lands first that adds visible product surface. The release rule on this repo is that minor bumps gate on visible product changes (a new feature, a restored UI affordance) and patch versions gate on bug fixes only. Everything in the unreleased array right now is a bug fix, so the natural cut would be a patch.

Read the unreleased array of CHANGELOG.json before you read the README. It is the part of the release log that shows what the maintainer thinks is wrong with the most recent tagged version, in their own words, before the marketing copy lands. If there is no unreleased section, that is itself information; the project is either shipped via a different convention or the maintainer is not tracking in-flight work in the open. Then look at how often the unreleased array gets emptied into a tagged release; weekly is healthy for a consumer app, monthly is fine for a library, quarterly suggests the project is dormant. Star counts and headline release notes are far weaker signals than the cadence of the unreleased section.