You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
tui: clicking a 1272x2015 inline image freezes the UI #60377
Clicking an inline image that is 1272×2015 pixels makes the OpenCode TUI unresponsive. Pressing Esc or Ctrl+C restores the UI.
OpenCode version
v2.2.2
Steps to reproduce
Display an inline image that is 1272×2015 pixels.
Click the image.
The TUI becomes unresponsive. Press Esc or Ctrl+C to restore it.
Operating System
Linux x86_64, CachyOS kernel 7.2.3-1-cachyos
Terminal
Kitty
Additional context
Reproduced with a synthetic solid-color PNG at 1272×2015 pixels (~12 KB), as well as with another image of the same dimensions. Images at 390×844 opened normally in 3/3 control attempts.
Running under Niri 26.04 (v26.04-85-gdd75865f). The active monitor is 2560×1600 at 240 Hz, scale 1, transform normal. The 1272×2015 value is the image size, not the monitor resolution.
Thanks for the detailed report, especially the 390×844 comparison and the synthetic test image.
We couldn't reproduce this here. The image viewer you open by clicking an image picks how to draw it from what the terminal supports, and in Kitty that's most likely Kitty's own image protocol. Our automated test terminal doesn't support that, so it would most likely draw the image as plain text characters and miss whatever goes wrong in Kitty. This needs a maintainer with Kitty on Linux to check.
Two things would help whoever picks it up:
Does the same 1272×2015 image hang in another terminal that can show images (e.g. WezTerm or Ghostty)?
While it's stuck, do any keys other than Esc do anything, e.g. ←/→ in the viewer? And is an image or a blank dialog on screen?
Activity
opencodejr commentedon Oct 29, 2026
Thanks for the detailed report, especially the 390×844 comparison and the synthetic test image.
We couldn't reproduce this here. The image viewer you open by clicking an image picks how to draw it from what the terminal supports, and in Kitty that's most likely Kitty's own image protocol. Our automated test terminal doesn't support that, so it would most likely draw the image as plain text characters and miss whatever goes wrong in Kitty. This needs a maintainer with Kitty on Linux to check.
Two things would help whoever picks it up:
Escdo anything, e.g.←/→in the viewer? And is an image or a blank dialog on screen?I didn't find an existing issue for this.
simonklee commentedon Oct 30, 2026
Have a fix for this incoming. Thanks for reporting.
simonklee commentedon Oct 31, 2026
In my local build that i'm currently testing i have resolved this. Once that's through testing i'll merge my changes.