desktop: software rendering fallback on OpenCore Legacy Patcher Macs (EGL init failure) #55786

Summary

The OpenCode 2 desktop app cannot initialize GPU rendering (EGL/Metal) on an OpenCore Legacy Patcher (OCLP) macOS installation and silently falls back to full software rendering. The UI becomes laggy, and the "OpenCode Helper (GPU)" process consumes ~a full CPU core whenever the UI repaints (typing, scrolling, streaming replies).

Environment

• opencode version: 2.0.29 (desktop app, Electron 44.4.5; CLI also 2.0.29)
• OS: macOS 14.8.9 (build 23J631, Darwin 23.6.0, x86_64), booted via OpenCore Legacy Patcher REL-106-2025-11-03; SIP custom configuration (kext signing disabled, filesystem protections disabled - typical for OCLP root patches)
• Hardware: MacBook Pro (Retina, 15-inch, Mid 2015) - MacBookPro11,4, Intel Core i7-4770HQ, Intel Iris Pro (system_profiler reports "Metal Support: Metal 2")
• Terminal: Not applicable (desktop app)
• Shell: /bin/zsh
• Install/channel: release/latest (desktop app auto-updater; CLI installed via the install script)
• Active plugins: none

Reproduction

1. Run the OpenCode 2 desktop app (2.0.29) on macOS 14 installed via OpenCore Legacy Patcher on an Intel Mac with Iris Pro graphics.
2. Open any session so the UI repaints (type, scroll, or have a reply stream in).
3. Watch the OpenCode Helper (GPU) process in Activity Monitor.

The issue is reproducible consistently. It also reproduces on a fresh second instance launched directly from the terminal with a clean --user-data-dir.

Expected Behavior

The app renders through ANGLE/Metal on the GPU, like other Chromium/Electron apps on the same machine. The GPU helper stays near 0% CPU when the UI is idle and the interface is smooth.

Actual Behavior

GPU initialization fails and Chromium falls back to software rendering:

ERROR:ui/gl/init/gl_initializer_mac.cc:127] GLDisplayEGL::Initialize failed.
ERROR:ui/gl/gl_display.cc:665] Initialization of all (1) EGL display types failed.

The GPU process is launched with --use-gl=disabled, and the GPU helper process burns 70-100% CPU while the UI is active (measured 93.9%, 94.2%, 97.8%, 99.8% at various times; 71.6% while a session was streaming; 1-2% when the UI is completely static).

On the same machine, other Chromium apps are unaffected and render in hardware - their GPU helpers idle at 0% (Arc: 0.0%, OpenChamber: 0.1%).

Workarounds tried (each in an isolated instance with a fresh user-data-dir):

• --ignore-gpu-blocklist → still EGL init failure, still software rendering
• --use-gl=angle --use-angle=metal → still EGL init failure
• --use-gl=angle --use-angle=gl → rejected by Chromium: Requested GL implementation (gl=egl-angle,angle=opengl) not found in allowed implementations: [(gl=egl-angle,angle=metal)].

So there is currently no launch flag that restores a working hardware path.

Additional Context

• OpenCode 1 desktop (1.19.0, Electron 42.x) did not exhibit this on the same machine, and OpenChamber (older Electron/Chromium) renders in hardware on the same machine, so the patched driver stack can still do accelerated rendering for older Chromium builds.
• Likely trigger: Chromium in Electron 44 only allows the ANGLE Metal backend on macOS, and EGL init fails against the OCLP-patched graphics stack.
• Related app logs live under ~/Library/Application Support/ai.opencode.desktop/logs/ (the EGL errors above were captured from the app binary's stderr on a direct launch).
• Suggestions:
  • Detect failed GPU initialization and surface a warning (and/or document the OCLP limitation).
  • Consider allowing the OpenGL ANGLE backend (--use-angle=gl) at least as an opt-in so legacy/patched macOS setups can use OpenGL.
  • Any reduction in UI repaint cost while in software fallback would also help older machines.