Repository navigation
High CPU usage since 1.1.60 using Ghostty #13490
Description
Description
Since version 1.1.60, when I have some plugins, and I run opencode in Ghostty, I have systematically high CPU usage.
- Without any plugins, it's ok.
- When I rollback to 1.1.59 with plugins, it's ok.
- When I switch to another Ghostty tab or another window, it stops the CPU usage.
- With Alacritty, it's ok.
I already tried to clean ~/.local/share/opencode and ~/.cache/opencode.
Plugins
@sveltejs/opencode
OpenCode version
1.1.65
Steps to reproduce
- add plugins like
@sveltejs/opencodeor@nick-vi/opencode-type-inject - run opencode in Ghostty
Screenshot and/or share link
No response
Operating System
Fedora Cosmic Atomic
Terminal
Ghostty
Metadata
Metadata
Assignees
Labels
No labels
Activity
github-actions commentedon Feb 13, 2026
This issue might be a duplicate of existing issues. Please check:
All of these report similar CPU/memory spikes when running opencode with plugins. This might help with finding the root cause if it's plugin-related.
[-]High CPU usage since 1.1.60[/-][+]High CPU usage since 1.1.60 using Ghostty[/+]dekoza commentedon Feb 13, 2026
I'm using ghostty and instead high CPU usage I see memory leaks since at least 1.1.56 - extended sessions grow up to 50% of memory, then it eats the CPU and gets killed.
segordon commentedon Feb 13, 2026
same here, but I see this after switching from konsole to ghostty for exactly the same reasons, so I tend to believe it's not the terminal emulator..
aaronnewsome commentedon Feb 13, 2026
For me, the memory usage spins out of control and then the system starts swapping like crazy and eventually my system is unresponsive completely. I added more ram to get to 8gb but it also exhausted that too. I have to kill the entire system to get control back since I can't ssh in, use the UI or really do much of anything except power down. I'm not using any plugins that I'm aware of, but for me the app is not usable in the current state. I've migrate the VM to another host and give it 32GB of ram to see if that helps but it seems excessive that it was even able to completely exahaust 4 and then 8GB of ram.
segordon commentedon Feb 13, 2026
If you can stand the possible process crashes I would suggest tuning whatever out-of-memory killer your system uses to be extra sensitive to the terminal emulator and opencode process to prevent total system instability. the only reason i'm not losing my VMs all together during these events is the use of an OOM killer w/ terminal emulator tuned to have a higher OOM score.
https://unix.stackexchange.com/questions/153585/how-does-the-oom-killer-decide-which-process-to-kill-first
it sucks to babysit the thing for when the emulator eats itself but at least it's a bit less friction ( maybe? ) than a VM restart.
sageil commentedon Feb 15, 2026
Using Ghostty with only superpowers plugin, it takes around 10 to 15 seconds to open with a noticeable CPU spike. Wezterm starts in less than 3 seconds using the same configs
akhansari commentedon Feb 16, 2026
It's definitively the TUI.
I have no issues with opencode web or using alacritty.
(I wish opencode was written in Rust or Go... First time I have so many issues with a CLI/TUI and my workflow is fully in terminal)
segordon commentedon Feb 17, 2026
i've had it crash in
opencode webmode more than a few times -- same messages in dmesg when it occurs as with the tui ; process out of memory - killed.I will say with certainty that it seems to take longer to crash when using the web mode, though.
github-actions commentedon Jul 3, 2026
To stay organized issues are automatically closed after 60 days of no activity. If the issue is still relevant please open a new one.