Repository navigation
Attaching a 3840x2160 PNG wedges the TUI and kills all terminal sessions #57621
Description
Description
Bug report: Large payloads into TUI input wedge opencode and kill all terminal sessions
Summary
Two distinct repros, same failure mode: pushing a large blob (image attach or clipboard paste)
through the opencode TUI wedges the whole box — all terminal windows die, keyboard rescue
(SysRq) needed. Long-running background jobs survive (launched with setsid), but every
interactive session is lost.
Environment
- OS: Linux (Arch-ish), kernel with xe Intel GPU driver
- Terminal: multiple terminals open (kitty/gnome-term), several tmux-style workflows
- opencode TUI session running alongside heavy GPU training job (31GB RAM box, ~19GB in use)
Repro 1 — attaching a 4K image
- Attach a 3840x2160 PNG (phone screenshot) to a TUI message
- opencode logs:
using resized image ... from=3840x2160 to=2000x1125 - ~90 seconds later the system is wedged; all terminals dead; SysRq required
Log evidence (~/.local/share/opencode/log/opencode.log):
timestamp=2026-10-21T02:44:16.392Z level=INFO run=a979b0c1 message="using resized image" from_mime=image/png to_mime=image/png from=3840x2160 to=2000x1125
timestamp=2026-10-21T02:52:53.520Z level=ERROR run=a979b0c1 message=process session.id=ses_ea5bca27cffer5Tr9dvNKbM42l messageID=msg_15c5f952e00117trwoJuZB0CKi error=Aborted stack=undefined
Kernel journal (same window):
Oct 21 12:45:47 ares kernel: sysrq: HELP : loglevel(0-9) reboot(b) crash(c) ...
Repro 2 — pasting large text
- Copy a large block of text to clipboard
- Paste into the opencode TUI input
- Same wedge: all terminals die, system unresponsive, recovery required
(Repro 2 has no log capture yet — box was wedged before a log pull was possible.)
Suspected common cause
Both paths push a multi-MB payload through the TUI input handling (base64 image data /
multi-hundred-KB paste text). Memory spike or blocking encode in the resize/paste path
appears to take down the TUI and its terminal children. The error=Aborted suggests a
Go runtime abort (possibly OOM) in the session process.
Frequency
Image crash: reproduced multiple times over several days (user reports "sometimes" —
correlates with 4K screenshots). Paste crash: reproduced at least once.
Workarounds
- Large text: write to a file and reference the path (
@/tmp/notes.txt) instead of pasting - Screenshots: save to disk first, attach by path
- Long jobs: always launch with
setsid/nohup— they survive the carnage
Impact
High: total loss of all interactive terminal sessions on the machine; rescue requires
SysRq or hard reboot. Data in running sessions is lost.
Plugins
No response
OpenCode version
No response
Steps to reproduce
No response
Screenshot
No response
Operating System
ubuntu
Terminal
gnome
Activity
opencode-agent commentedon Oct 21, 2026
Thanks for the detailed report, and sorry about the lost sessions.
The log line you quoted (
using resized image ... from=3840x2160 to=2000x1125) only comes from OpenCode v1 (versions 0.x/1.x, theopencode-ainpm package). v2 resizes images differently and doesn't write that line. v1 now only gets fixes for critical bugs. You already have a workaround (saving content to a file and referencing it by path), and the whole system wedging while a large GPU job was using most of the RAM suggests system-wide memory pressure, not something OpenCode does on its own. So this is unlikely to be fixed in v1.We'd encourage you to upgrade to v2 (
@opencode/cli, which provides theopencodecommand). It has a new image-resizing pipeline and TUI. If attaching a 4K screenshot or pasting a large block of text still hangs or crashes on v2, or you believe this is critical, please reply with:opencode --version~/.local/share/opencode/log/opencodeprocess was using before it hung, if you can see itThese may be related, ordered by likelihood:
opencode-agent commentedon Oct 22, 2026
We haven't heard back, so I'm closing this as not planned. The
using resized imagelog line shows this happened on OpenCode v1, which only gets fixes for critical bugs, and the workaround of attaching or referencing files by path still works.If the TUI still hangs on v2 (
@opencode/cli) when you attach a 4K screenshot or paste a large block of text, please open a new issue. Include the output ofopencode --version, the relevant lines from~/.local/share/opencode/log/, and the memory use of theopencodeprocess if you can. Thanks again for the detailed report.