Desktop: WebKit renderer process uses excessive memory (~7.5GB)

[athal7]

Description

The OpenCode Desktop app's WebKit renderer process (com.apple.WebKit.WebContent) grows to very high memory usage over time. In my case it reached ~7.5GB RSS, contributing significantly to system memory pressure.

Steps to reproduce

1. Open OpenCode Desktop
2. Use it for an extended session (several hours, multiple conversations)
3. Check memory usage: ps aux | grep WebKit | sort -rk6

Expected behaviour

WebKit renderer memory should stay bounded and be released between sessions or when not actively rendering.

Observed behaviour

The WebKit process grows unboundedly and is not released. On macOS it reparents to launchd (PID 1) making it look like an orphan, but it continues consuming memory. The process started at the same time as the Desktop app.

Plugins

opencode-pty, opencode-wakatime

OpenCode version

v1.3.0

Operating System

macOS (Apple Silicon)

Terminal

Ghostty

[github-actions]

This issue might be related to existing issues. Please check:

• [BUG/PERF] Severe Memory Leak and Disk Swell leading to System Kernel Panic (macOS) #12687: Severe memory leak and disk swell on macOS Desktop leading to kernel panic
• Opencode (1.2.24) leaks memory (until it's killed) #17237: General memory leak in opencode until OOM kill

If your issue is specifically about the WebKit renderer process growing unboundedly (as opposed to the opencode process itself), it may be a distinct root cause worth tracking separately.

[athal7]

Thanks for the pointers. The referenced issues (#12687, #17237) are about the main opencode process itself leaking memory (Go heap arenas, OOM kills on Linux). This issue is specifically about the WebKit renderer process (com.apple.WebKit.WebContent) in the Desktop app — a separate process managed by the OS WebKit framework, not the opencode process. The root cause is likely in how the Desktop app manages WebKit lifecycle (e.g. not releasing views/frames between sessions), which is a distinct code path. Keeping this open as a separate tracking issue.

[thdxr]

Closing in favor of #20695 where we're collecting all memory-related problems. Please follow that issue for updates.