A crowd-searchable log of third-party-app and system-process bugs seen on macOS 27 "Golden Gate" developer betas, with verified versions, log signatures, workarounds, and upstream / Apple Feedback links.
macOS 27「Golden Gate」开发者 beta 上撞到的第三方 app / 系统进程问题台账：含实测版本号、日志签名、临时规避、上游 / Apple Feedback 链接。方便后来撞坑的人直接搜到。
If a Google/GitHub search for a crash signature or a process eating CPU on macOS 27 beta brought you here — check the table below, open the matching file in issues/, and add your own data point via PR or issue.
| Machine | MacBook Pro Mac15,11 — Apple M3 Max, 36 GB |
| OS | macOS 27.0 beta — builds seen: 26A5353q (beta1), 26A5368g (beta2), 26A5378j (beta3), 26A5378n (beta3 revision, 2026-07-14), 26A5388g (beta4, 2026-07-21 → 08-11), 26A5406e (beta5 — released 2026-08-10, installed here 08-11) |
| Toolchain | Xcode 27.0 beta — 27A5194q (beta1, installed 2026-06-09/10, unchanged for 2 months) → 27A5237l (beta5, installed 08-11). Tracked separately on purpose: SDK-level entries (e.g. #11) move with this row, not the OS row |
| Reporter | @jizhi0v0 |
🔴 Open · confirmed, no fix | 🟡 Mitigated · workaround exists | 🟢 Fixed | ⚪ Needs retest
The
#in each row links to a matching GitHub Issue — Watch / 👍 / comment there to follow that specific problem. The Issue title links to the canonical, continuously-updated write-up inissues/. (Resolved/not-a-bug entries are tracked as closed issues.)每行的
#链到对应的 GitHub Issue(想跟进某个问题就在那 Watch / 👍 / 评论);问题标题链到issues/里持续更新的权威正文。已解决/非 bug 的条目对应 已关闭 的 Issue。🧭 "Clicking a notification does nothing"? Three unrelated defects share that symptom (#26 covers two of them, #27 the third). Classify yours from
usernoted's log first — notification-click-failure-taxonomy.md.🧭 「点击通知没反应」底下压着三个互不相干的缺陷,先按
usernoted的日志判型再对号入座。
| # | Issue | Component / 影响 | Status | Workaround (short) | Report |
|---|---|---|---|---|---|
| 1 | CoreMedia fpSupport_GetVideoRange… loop floods logd |
Apple MediaToolbox / CoreMedia | 🟡 still present on beta5 26A5406e (2026-08-11, captured in a deliberate post-boot window) — 1,744 hits in 8 min, emitters exactly as documented: DingTalk 1,338, WeType 263, Mail 136. Two changes vs beta1/2: the rate is lower (~2–6/s aggregate vs ~16/s per app) and logd costs 2.38% rather than ~20% — but it does not decay: it was still running at 2–6/s eight minutes in, where the original write-up said it dies down after a few minutes. The earlier ⚪ was a missed window, not a fix |
quit the WebKit apps / silence subsystem log | FB23411581 |
| 2 | Shortcuts/Siri ToolKit action-registration storm | Apple Shortcuts / siriactionsd | 🟡 still present on beta5 26A5406e (2026-08-11, deliberate post-boot capture) — peaks at 181 lines/s in the first full minute after boot (10,863 lines), then 14/s, then 1.4/s, then ~0 by minute 3. 12,421 lines total, 6,994 of them ToolKit; siriactionsd costs 1.77%. Self-settles exactly as documented. The earlier ⚪ "not reproduced in beta3 window" was a missed window — the storm lives entirely in the first ~3 minutes |
self-settles post-boot; silence subsystem log | Feedback: FB________ |
| 3 | WindowServer high CPU + Invalid window SkyLight loop |
Apple WindowServer / SkyLight | 🟢 fixed on beta5 26A5406e (2026-08-11) — the 42–46% floor is gone: ~4% on a clean idle desktop, 7.7% with the same menu-bar apps up. Distributions don't overlap — beta4's min across 10 replicates was 42.0%, beta5's max on a valid window is 6.9%. Invalid window survives at 0.5/s (was ~4/s), still decoupled from CPU. Cross-machine confirmation still outstanding — 🟢 is a this-machine verdict; #22's reporter saw the symptom return after 4–5 h on 26A5406e, but that shape (accumulates over uptime) is #22's layer, and it is being tracked there. No idle control has yet been run on second hardware. Second methodology trap, found by test-running the hand-off script before shipping it (2026-08-13): "~45% after killall MenuBarAgent" is not evidence of the floor. This machine — idle floor now ~4% — reads 66.0% → 47.8% and 45.2% → 45.5% across the restart on a working desktop (21 on-screen window owners). #22's 44.9% was likewise a working-desktop number, never an idle one, while the beta4 42–46% figures were idle: the two-layer corroboration argument compared numbers that were never like-for-like. A/B: tools/ws-ab-menubaragent.sh; the floor question is only answerable by the idle control in tools/ws-replicate.sh. Methodology trap recorded: a locked screen raises WindowServer CPU (the lock UI is animated), and pmset displaysleep does not govern it — the loginwindow screensaver idleTime does. One beta5 run was 73% locked and had to be voided; its apparent 5.7→24.5 "ramp" was the lock, not Alcove as first claimed |
n/a — fixed; the beta4-era note ("60 Hz doesn't help, quitting apps only removes load above the floor") described a floor that no longer exists | never filed — fixed before we got to it |
| 4 | Weather.app VFX thread spins ~36% CPU in background | Apple Weather.app 6.0 | 🟢 fixed (build 1435, incl. rain) | (was) killall Weather |
resolved on 26A5368g |
| 5 | OrbStack SwiftUI Charts → AttributeGraph abort | Apple SwiftUI / AttributeGraph ↔ OrbStack 2.2.1 → fixed in 2.2.2 | 🟢 fixed by the vendor in OrbStack 2.2.2 (2026-08-02, author-confirmed 08-03) — not by the OS. Last actually observed on beta1 only — never reproduced after that, but the workaround was in use the whole time, so the silence was never isolated to an OS change. The earlier 🟢 "not repro on beta2 (3h21m)" reasoning does not hold, and neither does the opposite claim that it kept reproducing | update to OrbStack 2.2.2 | orbstack#2526 — closed "Fixed in v2.2.2" |
| 6 | Chrome crash via MediaRemote Now-Playing nil | Apple MediaRemote ↔ Chrome | 🟢 not repro on .201 (2h churn) | — | resolved on .201 |
| 7 | ToDesk 10s crash-loop → "repeated logout" | ToDesk 4.9.7.1 (app bug) | 🟢 fixed in 4.9.7.2 | update to 4.9.7.2 (build 2064) | resolved |
| 8 | Codex Dock-tile plugin infinite recursion crash | Codex.app (app bug) | 🟢 likely fixed in 26.623.31443 | update Codex (0 crashes in 7 days) | openai/codex#27694 |
| 9 | Telegram lag = animated-content redraw (not MAS-specific) | Telegram-macOS 12.8 (native) | 🟢 explained | disable auto-play/animated stickers (any build) | not a build/Apple bug |
| 10 | WeChat (MAS) crash on launch — FIXED in 4.1.10 | WeChat 4.1.9 MAS | 🟢 | update to 4.1.10 (or use official build) | resolved |
| 11 | Swift Charts if/else fails to build under macOS 27 SDK |
Apple Swift Charts (SDK/build) | 🟢 fixed in the SDK shipped with Xcode 27 beta5 27A5237l (verified 2026-08-11 by A/B against 27A5194q on one machine — only A flipped, both controls held). Apple lists radar 174168981 as Resolved in the beta5 notes. Fix is a builder reroute, not a gate removal: buildEither dropped @_disfavoredOverload and gained obsoleted: 27.0, so sub-27 targets now lower to Charts.BuilderConditional (available since macOS 13) and never form _ConditionalContent — the @available(macOS 27.0) gate is still in the .swiftinterface. Corrects two earlier calls: it was never "by-design", and 27A5194q was the beta1 toolchain, not beta3 — beta2/3/4 SDKs were never tested |
upgrade Xcode, not macOS (SDK ships in Xcode); pre-beta5: bare if / ternary |
SDK bug, radar 174168981 |
| 12 | MenuBarAgent ~10–14% CPU at idle (static menu bar) | Apple MenuBarAgent | 🟢 fix holds on beta5 26A5406e (2026-08-11) — 0.57% cumulative over 4 h 42 m, and only 1.3% even while the menu bar is actively used. Holds beta3 → beta4 → beta5; the high readings were always Alcove-fed. Interaction condition finally measured, closing the gap with external report #20: driving the Control Center costs ControlCenter 2.1% → 33.5%, but a macOS 26.6 M4 mini cross-check gives 0.5% → 36.4% — slightly more — so that cost is intrinsic, not a beta regression. Also: MenuBarAgent does not exist on macOS 26 (the menu bar is driven by ControlCenter there), so neither process compares like-for-like across releases. #20's MenuBarAgent 20–70% remains unreproduced here |
quit/limit chatty menu-bar apps | FB23411741 |
| 13 | Spotlight typing lag / ghosting (insert ranking attr at NSNotFound) |
Apple Spotlight (UI app Campo→Siri AI on beta3) |
🟢 lag/ghosting fixed on beta3 (log line persists, now benign) | (was) use Raycast/Alfred | FB23412497 |
| 14 | Click/input latency — WindowServer ws_main_thread serializes events (persists at 80% idle) |
macOS 27 WindowServer / event delivery | 🟢 fixed on beta3 (Telegram panel-dismiss stutter gone; user-confirmed, settings-independent) | (was) Reduce transparency/motion | Feedback candidate FB____ |
| 15 | appstoreagent + dasd retry-loop (Arcade BG task rejected Code=8, no backoff) floods log/CPU |
Apple appstoreagent / dasd / BGTaskScheduler | ⚪ not reproduced in beta3 window (conditional) | killall = temporary; internal bug |
FB23413997 |
| 16 | modelmanagerd crash-loop (EXC_BREAKPOINT) on AI-ineligible device |
Apple modelmanagerd / ModelManagerServices | 🟢 fixed on beta3 (0 crashes ≥11h, trigger unchanged) | (was) none (SIP daemon) | FB23430737 |
| 17 | ViewBridge NSRemoteView uncaught ObjC exception on window order-on-screen (WeChat images and avatars + CleanShot X QuickLook + DingTalk + duo-pasted) |
Apple ViewBridge / AppKit (NSRemoteView) — hits WeChat 4.1.11 (Chromium), CleanShot X 4.8.9 (QuickLook), DingTalk 8.3.15 (Qt) & duo-pasted (Swift/AppKit) |
🟢 fixed in beta5 26A5406e — established by a beta4↔beta5 binary diff, not by absence of crashes. Apple changed exactly one method, the one that leaks the registration this crash needs: -[NSRemoteView maintainContainingWindowNotifications:] now removes the notification observers unconditionally and with object:nil (sweeping every stale per-window registration), where beta4 skipped removal whenever the weak _containingWindow ivar was already nil. ~10 source lines inserted in that method and nowhere before it, pinned independently by __LINE__-shift analysis. Residual gap: the sweep only runs when that method is called (its sole caller is byte-identical), assertion sites all remain, beta4 compared only as its x86_64 Rosetta build, and behavioural confirmation is still accumulating. Flips to 🔴 on first recurrence. Prior: 🔴 32 crashes, 4 apps / 4 UI toolkits, byte-identical at +216, surviving beta3→beta3rev→beta4 |
retry usually recovers; improved crash-guard + probe in tools/RemoteViewCrashGuard.m — the circulating forum version has two verified defects (installs nothing if called before ViewBridge lazy-loads; guards 1 of 3 assertion sites, containingWindowDidOrderOnScreen: has 2 more). Private-API swizzle either way, weigh before shipping |
Apple has acknowledged it (DTS, forum 837342; a third-party FB there shows "Potential fix identified — For a future OS update"). Ours FB____ still unfiled |
| 18 | contactsd self-sustaining change-history loop on CardDAV collection-groups | Apple contactsd 3837.100.1 / AddressBookManager / Contacts change-history |
🔴 still reproducing on beta5 26A5406e and the backlog is still growing: unconsumed group change rows went 53,686 (beta3) → 76,366 (beta5), +42%; worst single source 17,918 → 23,849. contactsd CPU 20.2% cumulative, ~218k log lines/hour. Two findings that supersede the original write-up: the 7 affected accounts span four different CardDAV providers (iCloud ×1, Google ×4, Yahoo ×1, one other) while the lone Exchange account is clean — ruling out a server-side quirk; and Could not fetch group for change type is emitted from Contacts.framework by 35 different processes (corespotlightd 750, AddressBookSourceSync 528, studentd 470, Mail 424 … contactsd itself only 45 per 30 min), not by contactsd alone |
none (loop is entirely Apple-internal — no app to quit) | FB24264605 — filed 2026-08-11 |
| 19 | imagent entitled to ContactsAccountsService but sandbox blocks the lookup → 1–2 ms no-backoff retry loop |
Apple imagent 10.0 (IMCore) ↔ ContactsAccountsService |
🔴 still reproducing on beta5 26A5406e (2026-08-11) — 6,522 ContactsAccountsService + 4,894 sandbox/deny lines / 30 min ≈ 13k/h (beta3: 66,626/7 h ≈ 9.5k/h), and still only 9 s of CPU — confirming it stays a log-volume bug, not a CPU one. Prior: 66,626 errors / 7 h on 26A5378n, shares #18's trigger |
none (SIP daemon; respawns on kill) | Feedback candidate FB____ |
| 22 | WindowServer ~100% cleared by restarting MenuBarAgent — structural-region state accumulation (external report by @andya1lan; tracked in the GitHub issue) | Apple WindowServer / SkyLight ↔ MenuBarAgent | 🔴 beta4-only; its corroboration of #3 no longer holds. That argument rested on its post-recovery 44.9% landing inside #3's 42–46% floor — and that floor is gone on beta5, so 44.9% would now be an anomaly rather than a match. This machine (M4 Air) is still on beta4 26A5388g and needs its own beta5 re-test. Prior: reproduced ×2 on beta4 on different hardware — ~98.5% → 44.9% on killall MenuBarAgent, recurring after ~2 d 9 h |
killall MenuBarAgent (temporary; clears the upper layer only) |
— |
| 20 | MenuBarAgent + ControlCenter 20–70% CPU when interacting with the menu bar (external report by @progzone122; tracked in the GitHub issue) | Apple ControlCenter / MenuBarAgent | 🟡 partly explained (2026-08-11) — the ControlCenter half is not a regression: driving the Control Center costs 2.1% → 33.5% here on beta5, and 0.5% → 36.4% on a macOS 26.6 M4 mini, i.e. slightly more on the older OS. The MenuBarAgent half (20–70%) is not reproduced here under either condition (0.3% idle, 1.3% in use) and stays open. Note MenuBarAgent does not exist on macOS 26 — the menu bar is driven by ControlCenter there — so neither process compares like-for-like across releases |
if MenuBarAgent is high, quit animated menu-bar apps (Alcove took it from ~22% to 0.0–0.1% here) | awaiting model / external-display / menu-bar-app details from the reporter |
| 21 | ControlCenter volume runaway — concurrent RMW ratchets volume to 0 or 100% | Apple ControlCenter (SoundSettings) ↔ CoreAudio HAL — trigger requires Alcove 1.7.9 |
🔴 not fixed — confirmed on beta5 26A5406e (supersedes the earlier 🟡; the issue file had been updated to 🔴 while this row still read 🟡). Confirmed on 26A5378n, 26A5388g and now 26A5406e; 10+ runaways captured in one day, both directions, both output devices, reproducible on demand. Not 27-specific — same symptom on 26.3.1 via Alcove #675; 30 Hz, ratchet step 1/16; trigger generalises to any output-device change |
killall ControlCenter; prevent by quitting Alcove |
FB23868196 · follow-up 2 still unsubmitted |
| 24 | mds floods the log with CoreDuet activity lines |
Apple Spotlight mds ↔ CoreDuet / contextstored |
🟡 bursty; peak rate was badly underestimated, but it does still settle (twice-corrected 2026-08-12). A 9 h 12 m watcher on beta5 26A5406e tripped its 300/s threshold 10 times, all inside one 2 h 23 m burst (17:43→20:06; min 302, median 585, max 5,976 lines/s), then 0 times in the following 6 h 49 m. So the earlier single-window reading (279/s peak) understated the peak by ~20×, but its "decays and settles" shape was right — the storm is burst-then-quiet, not sustained. |
none (silencing the subsystem hides the log, not the CPU) | Feedback candidate FB____ |
| 23 | ecosystemd trust-anchor re-evaluation retry loop |
Apple ecosystemd (Ecosystem.framework) ↔ Security / trustd |
🔴 still reproducing on beta5 26A5406e, at roughly half the beta4 rate on every axis (2026-08-11, 5 replicates on a quiesced desktop via tools/eco-replicate.sh) — CPU 16.4% (min 13.9, max 17.2, sd 1.3) vs beta4 26–57%; SecTrustCopyAppleTrustAnchors ~32.5/s vs ~68–85/s; 7,519 lines/60 s vs 15,885; 468 UNIX error exception: 5 vs 1,227. The failing-and-retrying shape is unchanged — this is mitigation, not a fix. Supersedes the earlier spot-checks (12.2% then 4.7%), which were taken under heavy load and disagreed with each other |
none | Feedback candidate FB____ |
| 25 | corebrightnessd emits all-nan brightness values at high frequency |
Apple CoreBrightness → QuartzCore | ⚪ RESOLVED 2026-08-13 — not a defect. nan is an unset-field sentinel written by Apple's code (three conventions coexist in one record: nan, -1.0, -1), not a failed computation: at the same instant a swap record prints ambient lux: nan, the sibling commitBrightness record carries a valid 419.248, matching corebrightnessd's own AggregatedLux 419.2484 — so the "Auto-Brightness runs on garbage input" argument was wrong. The one field that is never populated, indicator brightness, belongs to the on-screen secure camera indicator documented in Apple Platform Security (published 2026-03-11), which needs the dedicated silicon of MacBook Neo / A18 Pro; this Mac reports IOMFBSupportsSecureIndicator = No and its panel's IODeviceTree:/backlight node has no indicator property, so the channel is off and the field is nan forever — independent of macOS version. Falsification attempt that held: with the mic live (kTCCServiceMicrophone granted, sensor-indicator controller firing 3×) the field never moved — the orange dot is rendered on screen and does not use this channel. Evidence: 70,037 archived lines with 0 real values (8 apparent exceptions are the -1 sentinel), 10,501 corebrightnessd lines with 0 non-nan, 0 PIL activity in 3 h. Binary analysis by DeepSeek v4 Pro; all 7 cited strings re-verified here against the shared cache, instruction-level claims not re-verified. Also retired: the "% of windows with nan" metric is a churn measure, not a defect rate — the stream goes fully silent both with the display off and with it on but static (25 min observed). Prior call: 🔴 not rare — the "~once/30 min" call was wrong (corrected 2026-08-12). A watcher sampling a 5-minute window every ~5 min for 9 h 17 m on beta5 26A5406e found nan lines in 75 of 104 windows (72%), 37,088 lines total, peaking at 4,609 in a single 5-minute window. Still present on beta5, and frequent enough that any 5-minute look has a ~7-in-10 chance of catching it. Prior beta4 characterisation (1,396 toggles each way in 12 s at 120 Hz; every field incl. ambient lux reads nan with Auto-Brightness ON) stands; only the frequency estimate was wrong. Explicitly falsified as the cause of #3. Downgraded to 🟡 on 2026-08-13 after three corrections (rerunnable watcher: tools/corebrightness-nan-watch.sh): (a) the title's "~116 Hz toggle" is a brightness ramp, not an oscillation — an AggregatedLux change inserts SDR_RAMP, the key updates once per frame (120/s at 120 Hz) and stops when Finished ramps removes it 5.0 s later; below default log level, corebrightnessd costs 0.25–0.29%; (b) the NaN state itself is real and was being counted on the wrong stream — it belongs to WindowServer's (QuartzCore)[com.apple.coreanimation:Brightness], not corebrightnessd; on that stream, 30 min gives 24,809 lines, 96% with nan, 47% with ambient lux: nan; (c) not shown to be a 27 regression — the same log family appears on macOS 15.7 in an unrelated external report, and no valid cross-version control exists here (the 26.6 M4 mini has no internal display/ALS and logs 1 Brightness line in 3 h — code path not executing, not defect absent). Needs a macOS 26 laptop with built-in display + ALS to settle |
possibly disable auto-brightness (untested) | never filed — nothing to report; the behaviour is documented Apple design |
| 26 | Clicking a Chrome alert-style notification does nothing — getDeliveredNotifications returns empty for ~15 ms after add(), so Chrome kills its Alerts helper |
Apple UNUserNotificationCenter / usernoted ↔ Chrome Google Chrome Helper (Alerts).app |
🔴 root cause isolated to a system API, reproducible without Chrome (2026-08-12) — after add()'s completion handler has already fired, getDeliveredNotifications still returns an empty array for ~7–24 ms (median 15.4) on beta5 26A5406e, vs 0.01–0.03 ms, zero misses on macOS 26.6 (32 trials/OS, two passes, independently re-implemented). Chromium kills its Alerts helper on exactly that empty answer, so the helper dies (observed at 42 ms / 140 ms) while its notification is still on screen; the later click then reaches usernoted (16 Received response, 0 forwarded) but has no client, and the LaunchServices relaunch dies in ~100 ms because a Chromium helper cannot run standalone — 61 clicks → 60 appDeath → 2 forwards. Standalone Swift probe in tools/un-delivered-race-probe/. Falsified en route: Failed to source application bundle (fires on 26.6 too), helper liveness at delivery time, SW-version mismatch, elapsed time, WindowServer contention, killall usernoted/NotificationCenter |
wait for any other Chrome notification to arrive, or quit + reopen Chrome | Chromium: posted as comment #26 on issue 370536109 (open since 2024-10-01, same symptom, no root cause until now) · Apple: FB24273686 filed 2026-08-12 with both reproducers attached |
| 27 | Notification banner goes inert — activate and swipe dropped before usernoted, ✕ still works |
Apple — banner interaction, upstream of usernoted |
🔴 real, reproduced repeatedly, mechanism unknown (split out of #26 on 2026-08-12). Left click, right click and swipe-to-file all dead while the ✕ still works and tears down cleanly (_removeDelivered → _removeDisplayed → Spotlight de-index), so the channel is open and only the activate/swipe branches are dropped. 0 of 5 clicks reached usernoted as a banner vs 1 of 1 as a Notification Center row 13 ms to app launch. Not app-specific — hits Apple's own Reminders. Six hypotheses falsified (banner expiry, lock/unlock, UserNotificationCenter liveness — withdrawn as reverse causality, elapsed time, uptime, crash-looping); no trigger found, cannot be produced on demand. This is the symptom that started #26's investigation, and #26's filed reports do not cover it. No automated test possible: macOS ignores synthetic clicks on banners |
none — recovers on its own, unpredictably | not filed — no reproduction procedure to give Apple yet |
Each Apple bug was re-tested live on the machine before drafting Feedback, so we don't file stale/wrong reports. Ready drafts live in feedback/.
Re-ran the still-open Apple bugs on beta3 (installed 07:54, booted 07:53). Verdicts by live measurement, not changelog:
- 🟢 #12 MenuBarAgent idle CPU — fixed. 0.0% now, 43 s cumulative CPU TIME over 2h35m (≈0.28% avg); beta2 held 10–14% sustained. Cumulative-TIME can't be faked → confirmed fix.
- 🟢 #16
modelmanagerdcrash-loop — fixed. Daemon PID 830 alive ≥11 h with 0 crashes (many multiples of beta2's 2.5 h max interval); beta2 crashed ≤2.5 min after a clean reboot and every 20 min–2.5 h. Trigger condition unchanged — stilldeviceNotEligible,/var/db/com.apple.modelcatalog/still only emptysideload/tokenStore— so the daemon hits the same reconcile path without trapping = a real fix, not changed inputs. Passive durable watch continues (OS.ips+ launchdcom.jizhi.crash-notifylog every crash); flips back to 🔴 if a late-tail crash appears. - 🟢 #13 Spotlight typing lag / ghosting — fixed (log line persists, now benign). The user-facing bug was typing lag + a result "ghost" that lingered several seconds, not the log volume. Beta3: user reports smooth typing, no ghosting, and — objectively — 0 Spotlight-UI spin reports since boot vs 3×
Campo_*.spin(Slow response to HID event) on beta2 (2026-07-06). Theinsert ranking attr at NSNotFoundline still logs (peak 1569/sec) but is now decoupled from UX / benign spam. UI app renamedCampo→Siri AI. - 🟢 #14 Telegram panel-dismiss compositing stutter — fixed (user-confirmed 2026-07-08). The narrowed beta2 repro (group title → group-details → Back, dismissing the heavy blurred panel — a WindowServer/CoreAnimation frame-drop, fine on macOS 26) no longer stutters on beta3. User confirms it's the specific transition that's smooth now, and that toggling Telegram's animation/auto-play settings makes no difference — so it's the system compositor path that changed, not a content/settings workaround. Fits the beta3 compositor-fix cluster with #12/#13. (Objective note: this ~300 ms one-shot burst leaves no
.spin/.hangreport and WindowServer CPU is polluted by the agent's own rendering, so user perception of the exact narrowed repro is the evidence — same evidence class the #14 narrowing was built on.) - ⚪ #15 appstoreagent / #1 CoreMedia / #2 Shortcuts — not reproduced in this window (conditional triggers). Since boot: 0 appstoreagent lines / 0
Code=8; 0 CoreMediafpSupportspam; 0 Shortcuts-storm lines. These fire only under specific conditions (Arcade BG task rejection / WebKit DRM video / early post-boot), which didn't occur in the window — "not reproduced," not "confirmed fixed."
A beta3 revision 26A5378n replaced 26A5378j on 2026-07-14. Every verdict in the retest above was measured on …j and has not been re-measured on …n — treat them as carrying over unverified. The only entry re-checked on …n so far is #17, which kept crashing (11 crashes on …n, 07-14 → 07-19).
26A5378n 于 2026-07-14 替换 26A5378j。上面的复验结论全部测于 …j,尚未在 …n 上重测,请视为"沿用但未验证"。目前唯一在 …n 上复验过的是 #17 —— 仍在崩(…n 上 11 次,07-14 → 07-19)。
beta4 26A5388g — released by Apple 2026-07-20, installed here 07-21 — held for 21 days, until beta5 landed 08-10. So through that whole window none of the carried-over verdicts had a chance to be invalidated by a newer build; they simply remained unverified on …g.
The entry with by far the most beta4 data is #17, which keeps crashing — 13 times on beta4 alone (07-21 → 08-10), and has now spread to 4 apps across 4 UI toolkits (WeChat/Chromium, CleanShot X/QuickLook, DingTalk/Qt, duo-pasted/Swift-AppKit), byte-identical throw at +216. #21 was also reconfirmed on beta4. Everything else carries over from …n/…j unverified.
beta4 26A5388g(Apple 于 2026-07-20 发布,本机 07-21 安装)维持了 21 天,直到 08-10 beta5 发布。这段窗口内上面沿用的结论并非被新版本推翻,只是尚未在 …g 上验证。
beta4 数据最多的是 #17 —— 仍在崩,光 beta4 上就 13 次(07-21 → 08-10),且已扩散到4 个 app、4 种 UI 技术栈(微信/Chromium、CleanShot X/QuickLook、钉钉/Qt、duo-pasted/Swift-AppKit),抛点逐字一致于 +216。#21 亦已在 beta4 复验。其余结论均沿用 …n/…j,未验证。
A single 60 s /usr/bin/log show window (39,686 lines total) + a process-CPU snapshot, run to see which of the carried-over verdicts still hold. The machine was not idle during this pass (Claude 31%, Spotify 15%, Telegram, OrbStack all active), so CPU-floor questions (#3) are explicitly not answered here — those need the idle protocol in tools/ws-idle-baseline.sh.
一次 60 s 日志窗口(全系统 39,686 行)+ 进程 CPU 快照,用于检查沿用结论是否还成立。取样时机器并非空闲(Claude 31%、Spotify 15%、Telegram、OrbStack 均在跑),因此涉及 CPU 底噪的 #3 本轮不作结论 —— 那需要走 tools/ws-idle-baseline.sh 的空闲流程。
| Entry | Measured this pass | Verdict |
|---|---|---|
| #16 modelmanagerd | 0 crash reports on disk (incl. Retired/); daemon holds 6.7 s cumulative CPU over 24 h uptime |
🟢 fix holds on beta4 — first beta4 confirmation |
| #18 contactsd | 0 contactsd log lines in the window; 19 s cumulative CPU since boot (was ~143% bursts / 13% avg on …n) |
⚪ not reproducing in this window — trigger is CardDAV change-history, needs a dedicated window before claiming a fix |
| #19 imagent | 0 ContactsAccountsService lines; imagent 55 s cumulative CPU |
⚪ not reproducing — shares #18's trigger |
| #1 CoreMedia | 0 fpSupport_GetVideoRangeForCoreDisplay lines |
⚪ still conditional (needs WebKit DRM video); not reproduced |
| #2 Shortcuts storm | 0 BackgroundShortcutRunner, 2 benign siriactionsd lines |
⚪ post-boot-only trigger, uptime 24 h — window can't see it |
| #15 appstoreagent | 0 BGSystemTaskSchedulerErrorDomain Code=8; 5 appstoreagent lines, dasd 0.0% |
⚪ not reproduced |
| #13 Spotlight ranking attr | 0 — but idle is expected to be 0; the bug is typing-time only | ⚪ needs a typing window to retest |
#23 ecosystemd trust loop |
🔴 ACTIVE right now — top log emitter of the whole system: 7,177 lines/60 s (18% of all log volume), 4,061 SecTrustCopyAppleTrustAnchors calls/60 s ≈ 68/s, and 186 min cumulative CPU over 24 h uptime ≈ 12.7% of a core sustained |
🔴 confirmed still live on beta4 — strongest currently-reproducing entry |
#24 mds CoreDuet storm |
132 mds + 22 contextstored lines in the window; mds 0.0% |
⚪ not active in this window (was 145,241 lines/60 s) — bursty, needs catching live |
#25 corebrightnessd nan |
0 lines | ⚪ not caught in a 60 s window — but this counted the wrong process; the NaN lines are WindowServer's, and on that stream they run ~14/s (see the 2026-08-13 correction) |
| #3 WindowServer floor | WindowServer 41–45%, MenuBarAgent 8.1% — but under real app load |
Not yet retested on beta4 at all: #12's beta3 sibling verdicts #13 / #14 (both user-perception bugs — need the narrowed manual repro, not a log query), and #21 (already reconfirmed separately).
本轮尚未复验: #13 / #14 属用户感知类,需要手动走窄化复现路径,日志查询看不出来。
- ✅ Filed to Apple (confirmed beta2 bugs): CoreMedia loop → FB23411581 · MenuBarAgent idle ~10–14% CPU → FB23411741
- ✅ Filed: Spotlight
insert ranking attr at NSNotFound~60–160×/sec while typing (idle=0; intrinsic to ranking code, no Settings fix) → FB23412497 - ⏸ Intermittent — fires post-boot then self-settles; file with the captured boot-time evidence: Shortcuts/Siri storm (draft)
- 🔴 Ready to file — #19 imagent entitled to
ContactsAccountsServicebut sandbox omits the lookup (draft): the contradiction is provable statically in two greps — the binary holdsContactsAccountsService = true, whilecom.apple.imagent.sb's(allow mach-lookup)block lists the legacyAddressBook.abd(line 177) and noContactsAccountsServiceat all. Failure path then retries every 1–2 ms, no backoff → 66,626E-level lines / 7 h, but only 19 s CPU (log volume, not performance). No redaction needed. - ✅ Filed — #21 ControlCenter volume runaway (concurrent RMW race) (Control Center → Incorrect/Unexpected Behavior): caught live ×2 on one boot, ratcheting up to 100% and down to 0%+mute, on different devices (built-in speakers / Bluetooth) — direction and device both arbitrary, which is what rules out a stuck key and points at a lost-update race across ≥7 ControlCenter threads. Ratchet step is exactly 1/16, ~33 ms apart → full scale in ~0.5 s, no ramp (hearing-exposure hazard; led with this). Every write during the runaway is ControlCenter's own — the third-party precondition (Alcove 1.7.9) issues 0 writes in incident 2. Not a 27 regression: same up-direction symptom on 26.3.1 via Alcove #675, closed stale, repo archived read-only — no upstream channel left. Report states its own two limits (the "quit Alcove" result is uncounted; no first-discovery claim) → FB23868196 (draft · plain-text submitted body · details)
- ✅ Filed 2026-08-11 — #18 contactsd CardDAV collection-group change-history loop → FB24264605 (draft, details). Submitted with the beta5 re-verification on top of the beta3 forensics: backlog 53,686 → 76,366 rows (+42%), contactsd 20.2% CPU, ~218k log lines/hour, plus the two findings the original draft lacked — the 7 affected accounts span four CardDAV providers (Exchange clean), and the failing fetch is emitted by 35 processes from Contacts.framework, not by contactsd alone. Attachments: sysdiagnose, System Information Report,
migration.log. The.abcddbwas deliberately withheld (full contact data); the write-up's SQL lets Apple reproduce the row counts without it. - ✅ Filed —
modelmanagerdcrash-loop (EXC_BREAKPOINTonbackground-qos.cooperative, 138× in 4 days, reproduces ≤2.5 min after a clean reboot;deviceNotEligibleregion/account, HW-eligible M3 Max; trap is silent / binaries stripped, so no symbol or message to attach beyond the.ips+ queue + asset-set context) → FB23430737 (details) - 🟢 Not reproducing on beta2 — likely fixed (verified by live repro attempts, no Feedback needed):
- Weather VFX — backgrounded (incl. rain) at ~1% CPU, VFX threads parked; resolved in Weather build 1435.
- ~~OrbStack Charts — kept on the Activity Monitor view 3h21m, RSS plateaued ~150–185 MB (no runaway), no crash.~~
⚠️ This inference does not hold. A non-reproducing window is not evidence of a fix — and the workaround was in use, so not seeing it proves nothing either way. OrbStack shipped the actual fix app-side in 2.2.2 on 2026-08-02 — see the write-up. - Chrome MediaRemote — 1h45m of heavy Now-Playing churn on .201 (up to 640 events/min), no crash.
WindowServer high CPU — RESOLVED as load—⚠️ this beta2-era verdict has been overturned. It was based on a single un-replicated observation (quitting Telegram dropped CPU to single digits). On beta4, 10 replicates on a fully idle desktop show a ~42–46% floor that no app quit removes and that is independent of refresh rate. See row #3 above and the write-up; the GitHub issue was closed under the old verdict and needs reopening.
beta5 26A5406e — released 2026-08-10, installed here 08-11, ending beta4's 21-day run. Also swapped the toolchain the same day: Xcode 27A5194q → 27A5237l (both kept side by side for A/B).
Two entries have been retested on …e so far:
- #11 → 🟢, but it moved because of the Xcode swap, not the OS one.
- #21 → 🔴 still broken (2026-08-11, incident 5). Caught live: 60 writes/s across 11 ControlCenter threads, pinned at full scale on worn Bluetooth headphones,
coreaudiodat 185.8%, stopped only bykillall ControlCenter. The trigger narrowed — a single output-device switch is sufficient, with no tooling and no key hammering; meanwhile the repo's ownracetriggerrecipe failed 3× and is now understood not to reach the racing code path.
Every other verdict still carries over across two unverified build bumps (…n/…g → …e).
Read of Apple's beta5 release notes (fetched as the docs JSON and diffed by radar ID against the archived beta2 JSON — no beta3/beta4 snapshot exists on Wayback, so this diff spans beta2→beta5, not beta4→beta5):
- Of our 25 entries, exactly one is mentioned: #11, moved Known → Resolved (radar 174168981). The same entry is Resolved in the tvOS 27 and watchOS 27 beta5 notes too.
- #17 is not mentioned at all — no
NSRemoteView/ ViewBridge entry anywhere in the document. The third-party FB in forum 837342 showing "Potential fix identified — For a future OS update" is not evidence that beta5 is that update. Only a crash count on…ecan settle it. - None of our six filed FB numbers appear among the 24 FBs the document cites.
beta5 26A5406e(2026-08-10 发布,本机 08-11 安装),结束了 beta4 的 21 天。同日工具链也换了:Xcode 27A5194q → 27A5237l(两个并存,便于 A/B)。
目前有两条在 …e 上复验过:#11 → 🟢(但翻的是 Xcode,不是 OS);#21 → 🔴 仍未修复(08-11 事故 5,当场抓到:11 个 ControlCenter 线程、60 次/秒、钉在满刻度且反复撤销静音、coreaudiod 185.8%)。触发条件收窄:单次输出设备切换即可,不需要任何工具、也不需要猛按键;而仓库自带的 racetrigger 配方三轮全败,现已查明它够不到出错的代码路径。其余结论仍跨了两次未验证的 build 变更。
beta5 release notes 通读结论(抓 docs JSON,按 radar ID 与存档的 beta2 JSON 做 diff —— Wayback 上没有 beta3/beta4 快照,所以这是 beta2→beta5 的差集,不是 beta4→beta5):25 条里只提到 #11 一条(Known → Resolved);#17 全文未提,论坛里第三方 FB 的 "Potential fix identified" 不能证明 beta5 就是那个 update,只能靠 …e 上的崩溃计数说话;我们提交的 6 个 FB 号也都不在文档引用的 24 个里。
Open an issue or PR with: macOS build (sw_vers), app version + whether it's a Mac App Store build, the exact crash/log signature, and any workaround you found. One file per problem under issues/.
- Most Apple-framework regressions can't be fixed app-side — the realistic action is Apple Feedback Assistant. Each Apple entry has an
FB________slot; once filed, the Feedback ID gets pasted in so progress is traceable across betas. - "Verified versions" were read from the app bundles on the test machine, not copied from changelogs.
Not affiliated with Apple. Codename "Golden Gate" per public beta reporting.