Description
I've been hitting a recurring issue where opencode seems to keep growing in memory until it eventually gets killed by the Linux OOM killer.
When that happens, the terminal window is often left in a broken state. Mouse movement and key presses start showing up as raw escape sequences, the pointer can feel trapped inside the window, and the only reliable way out is to force-close it.
At first I thought this was a Hyprland problem, but after looking through logs and tracking memory over time, it looks more like opencode is the thing going wrong first, and the terminal/input breakage happens afterwards.
Environment
- Lenovo laptop
- Arch Linux / Kernel:
6.18.13-arch1-1
- Hyprland
- Kitty terminal
- opencode 1.2.24 / no plugin
- node 22.20.0
- bun 1.3.10
What happens
The issue is not easy to trigger on demand. It tends to happen after opencode has been running for a while.
From what I could gather:
opencode keeps increasing its memory usage over time- eventually the machine goes into memory pressure
- the kernel OOM killer selects
.opencode
- after that, the terminal is sometimes left in a corrupted input state
I attached memory graphs instead of pasting a wall of numbers, but the overall pattern is a clear upward trend followed by process death.
Why I think opencode is the root cause
I originally suspected either Hyprland or terminal mouse/input handling, because the visible symptom is a terminal that looks half-frozen and keeps printing control sequences.
But the logs consistently point to .opencode being OOM-killed, and the broken terminal state seems to happen after that abrupt termination.
So my current understanding is:
opencode grows in memory over time- the system hits heavy memory pressure
.opencode gets killed by the OOM killer- the terminal is left behind in a bad raw/input state
That makes the issue look compositor-related from the outside, but the trigger seems to be inside opencode.
Expected behavior
opencode should not keep growing in memory during normal use- even if it crashes or gets terminated, it should not leave the terminal in a broken state
Actual behavior
- memory usage keeps increasing over time
- the process eventually gets killed by OOM
- the terminal may become unusable afterwards and require force-closing
Description
I've been hitting a recurring issue where
opencodeseems to keep growing in memory until it eventually gets killed by the Linux OOM killer.When that happens, the terminal window is often left in a broken state. Mouse movement and key presses start showing up as raw escape sequences, the pointer can feel trapped inside the window, and the only reliable way out is to force-close it.
At first I thought this was a Hyprland problem, but after looking through logs and tracking memory over time, it looks more like
opencodeis the thing going wrong first, and the terminal/input breakage happens afterwards.Environment
6.18.13-arch1-1What happens
The issue is not easy to trigger on demand. It tends to happen after
opencodehas been running for a while.From what I could gather:
opencodekeeps increasing its memory usage over time.opencodeI attached memory graphs instead of pasting a wall of numbers, but the overall pattern is a clear upward trend followed by process death.
Why I think
opencodeis the root causeI originally suspected either Hyprland or terminal mouse/input handling, because the visible symptom is a terminal that looks half-frozen and keeps printing control sequences.
But the logs consistently point to
.opencodebeing OOM-killed, and the broken terminal state seems to happen after that abrupt termination.So my current understanding is:
opencodegrows in memory over time.opencodegets killed by the OOM killerThat makes the issue look compositor-related from the outside, but the trigger seems to be inside
opencode.Expected behavior
opencodeshould not keep growing in memory during normal useActual behavior