Opencode crashed , lagged my computer out, and outputted a bunch of gibberish to console #55213

Activity

1. opencode-agent commented on Oct 13, 2026

   

   opencode-agentBot

   on Oct 13, 2026 – with OpenCode Agent

   Contributor

   More actions

   Thanks for the report, and sorry about the trouble! There isn't enough here yet for us to figure out what went wrong. Could you share:

   1. What the "gibberish" was. If you can, paste some of the text (the first lines matter most). Was it a stack trace or error, escape-code-like text such as ^[[<35;12;8M or 8;6u, or something else? Did it keep printing after OpenCode exited?
   2. Provider and model you were using, and roughly what you asked it to do (for example, a big file edit or running a command).
   3. The lag. Did OpenCode use a lot of memory or CPU (for example in System Monitor) before it crashed?
   4. Logs from around the time of the crash, if there are any in ~/.local/share/opencode/log/.
   5. How you installed OpenCode, and whether it still happens on the latest release (v2.0.28 at the moment).

   You can reply here with the details, or edit the issue. If you edit it, please also leave a comment saying you've updated it so we know you're done.

   I found some possibly related issues, ordered by likelihood. You could check whether one of them matches what you saw:

   • tui: garbled display / raw ANSI on WSL when native audio backend writes ALSA errors to stderr #52793: on Linux/WSL, audio backend errors written to stderr garble the TUI with raw ANSI output when a turn finishes
   • OpenCode 2.x TUI becomes partially unresponsive while agent continues running #53165: the 2.x TUI becomes partly unresponsive while the agent keeps running
   • tui: stale terminal reply bytes leak into shell input after exit (paste shows "8;6u" garbage) #54500: leftover terminal reply bytes leak into the shell as garbage after exit
2. opencode-agent

   added

   triaging

   on Oct 13, 2026
3. italian-brainrot commented on Oct 13, 2026

   

   italian-brainrot

   on Oct 13, 2026

   Author

   More actions

   Thanks for the report, and sorry about the trouble! There isn't enough here yet for us to figure out what went wrong. Could you share:

   1. **What the "gibberish" was.** If you can, paste some of the text (the first lines matter most). Was it a stack trace or error, escape-code-like text such as `^[[<35;12;8M` or `8;6u`, or something else? Did it keep printing after OpenCode exited?
   
   2. **Provider and model** you were using, and roughly what you asked it to do (for example, a big file edit or running a command).
   
   3. **The lag.** Did OpenCode use a lot of memory or CPU (for example in System Monitor) before it crashed?
   
   4. **Logs** from around the time of the crash, if there are any in `~/.local/share/opencode/log/`.
   
   5. **How you installed OpenCode**, and whether it still happens on the latest release (v2.0.28 at the moment).
   

   You can reply here with the details, or edit the issue. If you edit it, please also leave a comment saying you've updated it so we know you're done.

   I found some possibly related issues, ordered by likelihood. You could check whether one of them matches what you saw:

   * [tui: garbled display / raw ANSI on WSL when native audio backend writes ALSA errors to stderr #52793](https://github.com/anomalyco/opencode/issues/52793): on Linux/WSL, audio backend errors written to stderr garble the TUI with raw ANSI output when a turn finishes
   
   * [OpenCode 2.x TUI becomes partially unresponsive while agent continues running #53165](https://github.com/anomalyco/opencode/issues/53165): the 2.x TUI becomes partly unresponsive while the agent keeps running
   
   * [tui: stale terminal reply bytes leak into shell input after exit (paste shows "8;6u" garbage) #54500](https://github.com/anomalyco/opencode/issues/54500): leftover terminal reply bytes leak into the shell as garbage after exit
   

   1. it was outputting endless amounts of stuff like 35;12;8M and yes it was printing it, and even when I pressed ctrl + C, it would still keep printing it, and it never stopped until I closed the terminal

   2. It was Space Bunny Free and I asked it to build a jar of a minecraft mod from github

   3. My computer froze for a minute and I wasn't able to open task manager to see because it was completely frozen, and then opencode crashed and it unfroze and started outputting gibberish to the terminal

   4. I dont have ~/.local/share/opencode folder

   5. It was using the curl command.
4. opencode-agent commented on Oct 13, 2026

   

   opencode-agentBot

   on Oct 13, 2026 – with OpenCode Agent

   Contributor

   More actions

   Thanks, that's really helpful!

   Here's what I think happened, in two parts:

   1. The freeze and crash. Your whole machine freezing for about a minute and then OpenCode dying looks like the TUI running out of memory. The system becomes unresponsive and the kernel then kills the process. That matches TUI OOM: intermittent 24-28GB memory exhaustion in v2, no trigger identified #51761, a known v2 bug where the TUI's memory grows by gigabytes in seconds. It was traced to the TUI rendering library (OpenTUI 0.5.12), and v2.0.21 updated it to 0.5.14. You're on v2.0.20, which still has the affected version.
   2. The endless 35;12;8M text. These are mouse-position reports from your terminal. OpenCode turns on mouse tracking while it runs. Because it was killed instead of exiting normally, it couldn't turn it back off, so every mouse movement got printed into your shell. That's why Ctrl+C didn't stop it: OpenCode was already gone. If it happens again, type reset and press Enter, or open a new terminal tab.

   Could you upgrade to the latest release and see whether it happens again? Since you installed with the curl script, run opencode upgrade, or run the install script again. Then check opencode --version; the latest release is currently v2.0.28.

   If it still happens on the latest version, please reply here with:

   • the version you're on,
   • roughly how long the session was and what the model was doing just before the freeze (for example, running a Gradle/Maven build or reading large files),
   • whether you resized the terminal window shortly before it happened (resizing was a frequent trigger in TUI OOM: intermittent 24-28GB memory exhaustion in v2, no trigger identified #51761).

   Related issues, ordered by likelihood:

   • TUI OOM: intermittent 24-28GB memory exhaustion in v2, no trigger identified #51761: TUI memory blows up to tens of GB and the machine locks up; fixed after v2.0.20
   • tui: RSS grows unbounded around ~300k-token sessions, OOM-killed at ~30 GB (v2.0.18, Linux) #51620: memory grows without limit in long sessions with large tool outputs (reported on v2.0.18)
   • v2.0.20: OpenCode reaches 28 GiB RSS (90.5% RAM) while idle or working #54286: v2.0.20 reaching about 28 GiB of RAM, the same version as yours
5. rekram1-node

   closed this as completedon Oct 16, 2026
6. opencode-agent

   closed this as not plannedon Oct 16, 2026
7. opencode-agent commented on Oct 16, 2026

   

   opencode-agentBot

   on Oct 16, 2026 – with OpenCode Agent

   Contributor

   More actions

   Closing this for now, since we haven't heard back. The freeze followed by the crash on v2.0.20 looks most like the memory problem in #51761. That was fixed in a later release (v2.0.21 updated the TUI rendering library). The endless 35;12;8M output was mouse reporting left switched on after OpenCode was killed; reset clears it.

   If it happens again after upgrading (opencode upgrade), please reply here or open a new issue. Include your opencode --version, roughly how long the session was, what the model was doing just before the freeze, and whether you had resized the terminal. Thanks for reporting!