Summary
On macOS, visible Buzz-related pages produced sustained renderer and compositor load, elevated WindowServer, and caused the MacBook's fan to run. A controlled hide/restore test showed the load disappearing almost immediately when Chrome was hidden and returning immediately when Chrome was restored.
Closing the main Buzz page caused a second Buzz-related page (Block — Introducing Buzz: where humans and agents work together) to become the active high-CPU renderer. After closing both pages and Buzz Desktop, the implicated renderer processes were gone, Chrome's GPU helper returned to approximately 1%, and the fan stopped.
The strongest direct attribution is to Buzz-related web content in Chrome. Buzz Desktop was open and newly installed, but its own process was not captured using high CPU, so this report does not claim the desktop executable alone caused the incident.
Environment
- Buzz Desktop: 0.5.2
- Bundle ID:
xyz.block.buzz.app
- Executable:
buzz-desktop
- Architecture: native ARM64
- Rendering framework: macOS WebKit
- Signature: Developer ID Application: Block, Inc. (
EYF346PHUG)
- Buzz app instance: PID 93577
- Buzz WebKit content process: PID 93582
- macOS: 27.0, build
26A5388g
- Hardware: MacBook Pro
Mac16,5, Apple M4 Max
- CPU: 16 cores (12 performance, 4 efficiency)
- GPU: 40 cores
- Memory: 64 GB
- Display: built-in 3456×2234 Retina display; no external displays
- Running Chrome during the incident: 150.0.7871.184, ARM64
macOS 27.0/build 26A5388g is a prerelease environment, so a WebKit/Chrome/WindowServer interaction specific to this OS remains possible.
User-visible impact
- Audible sustained fan
- Rapid power/battery use
- Activity Monitor showed
WindowServer around 75% CPU
- The fan stopped after both Buzz-related Chrome tabs and Buzz Desktop were closed
macOS process CPU percentages are per core. Therefore, 75% for WindowServer means roughly three-quarters of one CPU core, not 75% of the entire 16-core machine.
Initial measurements
Repeated live samples showed:
| Process |
PID |
CPU |
WindowServer |
628 |
74.7–76.2% |
| Chrome GPU helper |
66230 |
39.9–47.5% |
| Buzz Chrome renderer |
47303 |
21.0–32.1% |
Chrome's Task Manager positively identified PID 47303 as:
Tab: Buzz — Your people, your agents, your project — all in one place.
At capture time it showed:
- CPU: 31.8%
- Memory: 131 MB
- PID: 47303
Chrome's GPU helper had a 1.4 GB physical footprint with a 2.2 GB peak. The Buzz renderer had a 131.4 MB footprint with a 293.4 MB peak.
A native macOS process sample of the GPU helper showed active QuartzCore/CoreAnimation transaction commits and graphics-surface/layer work. That establishes continuous painting/compositing activity, but it does not by itself identify whether the source was CSS animation, requestAnimationFrame, canvas, video, WebGL, or another mechanism.
Controlled hide/restore test
Chrome was hidden for eight seconds without closing or changing its tabs.
| State |
WindowServer |
Buzz renderer |
Chrome GPU |
| Chrome visible |
89–92% |
27–32% |
42–47% |
| Chrome hidden |
72–79% |
0–0.7% |
0–0.6% |
| Chrome restored |
90–92% |
25–34% |
42–48% |
The renderer and GPU processes reached effectively zero within about one second of hiding Chrome, then returned to their prior levels as soon as Chrome was restored.
This was repeatable within the controlled test and is the strongest causal evidence collected.
Second Buzz-related page
Chrome's Task Manager also identified:
Tab: Block — Introducing Buzz: where humans and agents work together.
- PID: 46489
- Memory at initial inspection: 183 MB
- Associated dedicated worker under
block.xyz
After the main Buzz dashboard tab was closed, PID 47303 disappeared, but PID 46489 then sustained 34.7–41.9% CPU. During this phase:
- Chrome GPU was approximately 3.9–4.7%
WindowServer was approximately 52.7–59.8%
This suggests the second Buzz-related page also performs sustained work while active, though it appears less GPU-heavy than the main Buzz dashboard.
After closing all Buzz surfaces
The following processes were absent:
- Buzz Desktop PID 93577
- Buzz WebKit processes 93580 and 93582
- Main Buzz Chrome renderer PID 47303
- Introducing Buzz Chrome renderer PID 46489
Post-closure observations:
- Chrome GPU helper: approximately 0.8–0.9%
WindowServer: approximately 42–55%, with other live diagnostic UI and unrelated system activity still present- User-reported fan state: off
Buzz Desktop log observations
Buzz Desktop itself was generally around 0–2% CPU in the available samples. Closing the desktop app was not isolated from closing the remaining web page, so its independent contribution was not measured.
Its unified logs nevertheless contained items worth reviewing:
WebContent[93582] Conn 0x0 is not a valid connection ID. repeated at startup- Camera/Core Media initialization errors, including an invalid or unavailable background-replacement pixel-buffer size
- Core Media parameter errors
- Core Audio registrar/property failures
- WebKit sandbox denials involving networking and audio services
- Repeated CoreSpotlight donation failures
- Media/audio cleanup errors during shutdown
If the user had not entered a voice huddle, the camera and audio initialization is notable. It may be worth checking whether media infrastructure is initialized eagerly at app startup rather than only when required.
These log messages were not proven to cause the compositor load and may include normal sandbox or prerelease-macOS noise.
WindowServer log observations
During the investigation, WindowServer also logged invalid-window constraint operations, cursor-surface failures, cleared client buffers, and one Could not find display 0x0 message.
However, invalid-window messages occurred before, during, and after Buzz was running. They cannot reliably be attributed to Buzz and are included only as environmental context.
Probable fault class
The evidence is consistent with a Buzz web surface that does not quiesce when visually stable. Candidate causes include:
- An unrestricted
requestAnimationFrame loop
- A continuously repainted canvas or visualization
- CSS/JavaScript animation running at display refresh rate
- Repeated live-state/component updates without user input
- Animated media or video continuously decoding/compositing
- Missing
visibilitychange/background-window handling
The controlled test proves that visible Buzz-related content drove substantial renderer/GPU work. It does not identify the exact frontend mechanism.
Suggested investigation
- Capture Chrome Performance profiles for the Buzz dashboard and the “Introducing Buzz” page while visible and idle.
- Inspect main-thread scripting, frame rate, paints/composites,
requestAnimationFrame, canvas/video/WebGL, and component updates without input.
- Verify rendering loops pause on
document.visibilitychange, tab backgrounding, window minimization, offscreen elements, and app deactivation.
- Profile Buzz's WKWebView build separately with Time Profiler, Core Animation, Energy Log, and Metal System Trace if applicable.
- Review whether camera, microphone, and Core Media components can be initialized lazily when entering a huddle.
- Reproduce on both macOS 27 build
26A5388g and a stable macOS release.
A useful idle acceptance check would be: after 60 seconds without interaction, a visually stable renderer should remain below roughly 2–5% of one core while visible and approximately 0–1% while hidden.
Reproduction status
The visibility test was deterministic during this incident, but a fresh-launch reproduction has not yet been attempted because the immediate goal was to stop the unexpected load and fan. No application settings or user data were modified.
Related but apparently distinct issues
Raw native sample(1) reports for the Buzz Chrome renderer and Chrome GPU helper were captured locally and can be provided if useful.
Summary
On macOS, visible Buzz-related pages produced sustained renderer and compositor load, elevated
WindowServer, and caused the MacBook's fan to run. A controlled hide/restore test showed the load disappearing almost immediately when Chrome was hidden and returning immediately when Chrome was restored.Closing the main Buzz page caused a second Buzz-related page (
Block — Introducing Buzz: where humans and agents work together) to become the active high-CPU renderer. After closing both pages and Buzz Desktop, the implicated renderer processes were gone, Chrome's GPU helper returned to approximately 1%, and the fan stopped.The strongest direct attribution is to Buzz-related web content in Chrome. Buzz Desktop was open and newly installed, but its own process was not captured using high CPU, so this report does not claim the desktop executable alone caused the incident.
Environment
xyz.block.buzz.appbuzz-desktopEYF346PHUG)26A5388gMac16,5, Apple M4 MaxmacOS 27.0/build
26A5388gis a prerelease environment, so a WebKit/Chrome/WindowServer interaction specific to this OS remains possible.User-visible impact
WindowServeraround 75% CPUmacOS process CPU percentages are per core. Therefore, 75% for
WindowServermeans roughly three-quarters of one CPU core, not 75% of the entire 16-core machine.Initial measurements
Repeated live samples showed:
WindowServerChrome's Task Manager positively identified PID 47303 as:
At capture time it showed:
Chrome's GPU helper had a 1.4 GB physical footprint with a 2.2 GB peak. The Buzz renderer had a 131.4 MB footprint with a 293.4 MB peak.
A native macOS process sample of the GPU helper showed active QuartzCore/CoreAnimation transaction commits and graphics-surface/layer work. That establishes continuous painting/compositing activity, but it does not by itself identify whether the source was CSS animation,
requestAnimationFrame, canvas, video, WebGL, or another mechanism.Controlled hide/restore test
Chrome was hidden for eight seconds without closing or changing its tabs.
The renderer and GPU processes reached effectively zero within about one second of hiding Chrome, then returned to their prior levels as soon as Chrome was restored.
This was repeatable within the controlled test and is the strongest causal evidence collected.
Second Buzz-related page
Chrome's Task Manager also identified:
block.xyzAfter the main Buzz dashboard tab was closed, PID 47303 disappeared, but PID 46489 then sustained 34.7–41.9% CPU. During this phase:
WindowServerwas approximately 52.7–59.8%This suggests the second Buzz-related page also performs sustained work while active, though it appears less GPU-heavy than the main Buzz dashboard.
After closing all Buzz surfaces
The following processes were absent:
Post-closure observations:
WindowServer: approximately 42–55%, with other live diagnostic UI and unrelated system activity still presentBuzz Desktop log observations
Buzz Desktop itself was generally around 0–2% CPU in the available samples. Closing the desktop app was not isolated from closing the remaining web page, so its independent contribution was not measured.
Its unified logs nevertheless contained items worth reviewing:
WebContent[93582] Conn 0x0 is not a valid connection ID.repeated at startupIf the user had not entered a voice huddle, the camera and audio initialization is notable. It may be worth checking whether media infrastructure is initialized eagerly at app startup rather than only when required.
These log messages were not proven to cause the compositor load and may include normal sandbox or prerelease-macOS noise.
WindowServer log observations
During the investigation, WindowServer also logged invalid-window constraint operations, cursor-surface failures, cleared client buffers, and one
Could not find display 0x0message.However, invalid-window messages occurred before, during, and after Buzz was running. They cannot reliably be attributed to Buzz and are included only as environmental context.
Probable fault class
The evidence is consistent with a Buzz web surface that does not quiesce when visually stable. Candidate causes include:
requestAnimationFrameloopvisibilitychange/background-window handlingThe controlled test proves that visible Buzz-related content drove substantial renderer/GPU work. It does not identify the exact frontend mechanism.
Suggested investigation
requestAnimationFrame, canvas/video/WebGL, and component updates without input.document.visibilitychange, tab backgrounding, window minimization, offscreen elements, and app deactivation.26A5388gand a stable macOS release.A useful idle acceptance check would be: after 60 seconds without interaction, a visually stable renderer should remain below roughly 2–5% of one core while visible and approximately 0–1% while hidden.
Reproduction status
The visibility test was deterministic during this incident, but a fresh-launch reproduction has not yet been attempted because the immediate goal was to stop the unexpected load and fan. No application settings or user data were modified.
Related but apparently distinct issues
/; different process attribution and root causeRaw native
sample(1)reports for the Buzz Chrome renderer and Chrome GPU helper were captured locally and can be provided if useful.