Desktop (macOS, Electron): high CPU usage during active use, CHROME_HEADLESS=1 works around it, but silently disables all window shadows #48120

Description

Problem: high CPU during active use

During active use (terminal output streaming, AI responses rendering, scrolling), the desktop app consumes an unreasonable amount of CPU.

Workaround:

launchctl setenv CHROME_HEADLESS 1   # applies to all GUI apps at login

(or a per-app LaunchAgent wrapper setting the var only for OpenCode)

With the variable set, CPU usage under the same workload drops significantly (reproducible across relaunches). Idle CPU is ~0% in both states; the burn is usage-dependent.

Side effect of the workaround: CHROME_HEADLESS is read by Chromium's remote_cocoa layer as a bot workaround that force-disables window shadows for the whole process: components/remote_cocoa/app_shim/native_widget_mac_nswindow.mm:

bool AreWindowShadowsDisabled() {
  // ...disable window shadows when running on a bot
  static bool is_headless = getenv("CHROME_HEADLESS") != nullptr;
  return is_headless;
}

- (void)setHasShadow:(BOOL)flag {
  [super setHasShadow:flag && !AreWindowShadowsDisabled()];
}

Every OpenCode window loses its drop shadow (especially visible because the app uses titleBarStyle: "hidden" + trafficLightPosition on macOS), and it cannot be re-enabled from the Electron main process: win.setHasShadow(true) goes through the same swizzled setter and is clamped. Because launchctl setenv is login-wide, every other Chromium/Electron app the user runs also loses shadows.

Questions worth investigating upstream:

• What does CHROME_HEADLESS actually change for an Electron renderer here? The only consumers in Chromium are: the macOS window-shadow bot workaround (see above), NativeWindowOcclusionTracker (Windows-only), and crash-reporter behaviour. The CPU improvement suggests occlusion/visibility tracking is involved, possibly the app's windows being marked occluded/throttled, or a vsync/occlusion-related compositor path differing when the var is set.
• Is there a supported switch that achieves the same effect without the side effects? (e.g. an Electron flag or app setting controlling the same compositor/occlusion behaviour.)

Suggested fixes

1. Fix the CPU issue directly so the env var isn't needed. Profiling the renderer during active use with/without the var would likely point at the culprit (occlusion-driven throttling vs. missing throttling, compositor scheduling, PTY output rendering, etc.).
2. If the CPU issue can't be fixed soon, consider a supported opt-in (Electron command-line switch or app setting) that reproduces whatever CHROME_HEADLESS changes for CPU without the shadow/occlusion side effects.
3. Expose a way to restore shadows when the var is present, e.g. call through to the underlying NativeWidgetMacNSWindow super implementation of setHasShadow: (bypassing the swizzle), or invoke the disableHeadlessMode path Electron already has (ElectronNSWindow) at window-show time.
4. At minimum: document that CHROME_HEADLESS=1 disables all window shadows in every Chromium/Electron app, so users applying it as a CPU workaround understand the trade-off.

Notes for triage

• The app's app.asar never reads CHROME_HEADLESS; the reader is Chromium/Electron framework code (strings on Electron Framework shows the symbol adjacent to the remote_cocoa headless-window code native_widget_mac_nswindow_headless.mm and screen_mac_headless.mm).
• Upstream context: https://crbug.com/899286 (window-server crashes with shadows + software compositing, the reason for the bot workaround) and https://source.chromium.org/chromium/chromium/src/+/main:chrome/common/env_vars.h (kHeadless = "CHROME_HEADLESS").

Plugins

No response

OpenCode version

1.18.29 (Electron 42.3.3)

Steps to reproduce

1. Use the app under active load (terminal output streaming, AI responses rendering, scrolling) → CPU usage is unreasonably high.
2. launchctl setenv CHROME_HEADLESS 1 (or a per-app LaunchAgent wrapper), relaunch → CPU drops significantly, but every window loses its drop shadow.
3. launchctl unsetenv CHROME_HEADLESS, quit + relaunch → shadows are back, high CPU returns.

A/B tested across relaunches: shadow presence tracks the variable 100% of the time. Window nudges, re-ordering, and fullscreen toggles do not restore shadows.

Screenshot and/or share link

No response

Operating System

MacBook Pro (M1 Max), macOS 27.0 Beta (26A5421a)

Terminal

N/A (desktop app)