TUI hangs in tmux after opentui 0.1.103 upgrade (theme detection)

Description

After the opentui upgrade from 0.1.99 to 0.1.103 in commit 3a5507d, the TUI becomes unresponsive when running inside tmux. Every keystroke lags significantly, making the app unusable.

Root Cause

0.1.103 introduced renderer.waitForThemeMode(timeout) which sends OSC escape sequences to detect the terminal's background color. tmux doesn't forward these properly, so the call blocks for the full timeout duration on each render cycle — not just once at startup.

The call site is in packages/opencode/src/cli/cmd/tui/app.tsx:133:

const mode = (await renderer.waitForThemeMode(1000)) ?? "dark"

Reproduction

Open a tmux session
Run opencode (built from dev branch with opentui >= 0.1.103)
Try typing — keystrokes are delayed by ~1 second each
Exit tmux, run opencode directly — works fine

Workaround

Pin opentui back to 0.1.99 in package.json and replace the waitForThemeMode call with a hardcoded "dark".

Environment

Linux (WSL2)
tmux 3.5a
Terminal: Windows Terminal / wezterm
TERM: xterm-256color

This issue might be a duplicate of or closely related to existing issues. Please check:

bug: typecheck fails on dev — waitForThemeMode does not exist on CliRenderer #23504: Directly references the same waitForThemeMode call at the same code location (app.tsx:132) — that issue reports a typecheck failure because waitForThemeMode doesn't exist on CliRenderer in the pinned opentui version; your issue describes the runtime consequence of using it in a newer opentui version where it blocks in tmux.
Screen lag/freezing when typing text (WSL2, TMUX, Alacritty) #8484: Screen lag/freezing when typing in WSL2 + tmux — similar symptoms (significant input lag inside tmux), though reported with an older opentui version and different root cause.
Auto theme mode does not work in tmux popup #19254: Auto theme mode does not work in tmux popup — related issue where OSC-based theme detection fails specifically inside tmux contexts.

If your issue is distinct from the above, feel free to keep it open. Otherwise, consider referencing or closing in favour of the most relevant existing issue.

Can confirm a very similar issue on the current release.

Environment:

opencode 1.14.25
tmux 3.6a
macOS
Ghostty

When I run opencode inside tmux, the TUI hangs / becomes very sluggish in a way that feels consistent with the theme-detection issue described here. I’m seeing this on the released build (1.14.25), not just on dev.

Also have this issue but only within vscode's integrated terminal. Running on external Alacritty work fine.

opencode 1.14.25
tmux 3.6a
linux 6.19.13.arch1-1
Alacritty

The above work around solved my issue.

i am a tmux user and i haven't seen this. is it possible to share tmux config to see if we can reproduce?

Same problem in tmux. opencode works in ghostty but when you run in tmux it starts strobbing.

Better in 1.14.26?

It’s not reproducible for me in 1.14.26. Thanks!

@thdxr

v1.14.26 fixed for me as well

@thdxr workaround for me was set -g allow-passthrough off on tmux config.
Opencode seems to probes Kitty graphics via DCS-wrapped APC and stalls on the response path.

Down below was my debugging session with claude

TUI hangs / input lag inside tmux when allow-passthrough on

Summary

The opencode TUI freezes on startup when launched inside a tmux pane that has set -g allow-passthrough on. The cursor blinks rapidly in the top-left corner, the prompt input box never accepts keystrokes,
and the UI never finishes painting. Outside tmux (Ghostty directly) it works perfectly.

This appears to be the same root cause as upstream issue #24475 — the renderer.waitForThemeMode(1000) call introduced in opentui 0.1.103 (commit
3a5507d) sends OSC background-color probes that don't round-trip cleanly through tmux, blocking each render cycle for the full 1s timeout.

Environment

Field Value

opencode version 1.14.25 (Mach-O arm64, Bun-compiled)

Outer terminal Ghostty (with Ghostty's bundled terminfo on TERMINFO)

tmux 3.6a

Shell nu (also reproduces from bash -c 'opencode --pure')

OS macOS, Darwin 25.4.0 (arm64)

TPM plugins tmux-sensible, tmux-yank, tmux-resurrect, tmux-continuum

Symptoms

Cursor blinks rapidly at column 0, row 0 — the prompt frame is never drawn or never receives focus.

Keystrokes are not echoed.

Ctrl-C eventually exits.

Outside tmux: starts and runs normally.

Repro

Launch Ghostty (or any terminal) with a tmux config that has set -g allow-passthrough on.

Inside the tmux pane, run opencode (or opencode --pure).

Observe the hang.

What I tried that did not help

env -u NODE_OPTIONS opencode (rule out preload injection from third-party MCP/hook).

opencode --pure (rule out plugin handshake).

tmux kill-server then fresh attach so default-terminal "tmux-256color" actually applies.

TERM=tmux-256color, TERM=screen-256color (force generic terminfo).

env -u TERMINFO -u GHOSTTY_RESOURCES_DIR -u GHOSTTY_BIN_DIR TERM_PROGRAM= COLORTERM= opencode --pure (hide Ghostty identity from capability probes).

tmux set-option -g focus-events off.

Launching from bash -c instead of nu.

Bisect

Reduced ~/.config/tmux/tmux.conf to three minimal variants (no TPM, no powerline). Each launched via tmux -f <file> new-session after tmux kill-server:

Variant Contents Result

T1 — full settings minus TPM default-terminal, terminal-features, terminal-overrides, extended-keys, mouse, mode-keys vi, allow-passthrough on, escape-time 0, history-limit HANGS

T2 — minus terminal-features/overrides/extended-keys default-terminal, mouse, mode-keys vi, allow-passthrough on, escape-time 0, history-limit HANGS

T3 — minus allow-passthrough on default-terminal, mouse, mode-keys vi, escape-time 0, history-limit WORKS

Single-variable difference between T2 and T3 isolates the culprit to set -g allow-passthrough on.

Captured escape stream (script(1) on macOS, before workaround)

opencode --pure startup sends:

ESC[?2031h — color theme change notifications

DCS tmux; ESC ESC]10;? BEL ESC ESC]11;? BEL ESC \ — tmux-wrapped OSC 10/11 fg/bg color queries

ESC[>0q — XTVERSION

ESC[?25l ESC[s ESC[6n — hide cursor, save, DSR cursor position

DCS tmux; ESC ESC[?1016$p ESC ESC[?2027$p ESC ESC[?2031$p ESC ESC[?1004$p ESC ESC[?2004$p ESC ESC[?2026$p ESC \ — wrapped DECRQM batch

ESC[?u — Kitty keyboard protocol query

ESC]66;w=1; ESC \ and ESC]66;s=2; ESC \ — OSC 66 grapheme-cluster width probes (NOT wrapped in tmux passthrough DCS)

ESC[?1049h ESC[>4;1m ESC[?2004h ESC[?1000h ESC[?1002h ESC[?1003h ESC[?1006h — alt-screen, modifyOtherKeys, bracketed paste, mouse modes

ESC[14t — pixel-size report

DCS tmux; ESC ESC_Gi=31337,s=1,v=1,a=q,t=d,f=24;AAAA ESC ESC \\ ESC ESC[c ESC \ — Kitty graphics capability probe wrapped in tmux passthrough, followed by DA1

ESC]4;0;? BEL … ESC]4;37;? BEL — palette queries for indices 0–37

The Kitty graphics probe is the one that requires allow-passthrough on to reach Ghostty. With passthrough on, the response path stalls (matching #24475's description that waitForThemeMode blocks
per-render). With passthrough off, tmux drops the wrapped DCS silently and opencode falls back to a default theme — TUI starts immediately.

Workaround

Disable Kitty-graphics passthrough in tmux:
# ~/.config/tmux/tmux.conf
# set -g allow-passthrough on   # opencode hangs in tmux until upstream opentui fix
Then tmux kill-server and reattach.

Trade-off: image-preview tools (yazi, timg, kitten icat) lose Kitty graphics inside tmux. Re-enable temporarily per-session with tmux set -g allow-passthrough on after opencode has started, if needed.

Suggested fix (upstream)

Per #24475: either remove the per-render waitForThemeMode call, cache the result after the first probe, or use a much shorter timeout (e.g. 50–100 ms) when the terminal is detected as tmux ($TMUX set, or
XTVERSION reply contains tmux). Hardcoding "dark" as a fallback is acceptable for tmux sessions.

References

Upstream: TUI hangs in tmux after opentui 0.1.103 upgrade (theme detection) #24475

opentui regression: commit 3a5507d (0.1.99 → 0.1.103)

Call site: packages/opencode/src/cli/cmd/tui/app.tsx:133

My issue is fixed within opencode 1.14.28. I also had set -g allow-passthrough on
Thank you

To stay organized issues are automatically closed after 60 days of no activity. If the issue is still relevant please open a new one.

Navigation Menu

Repository navigation

TUI hangs in tmux after opentui 0.1.103 upgrade (theme detection) #24475

Description

Root Cause

Reproduction

Workaround

Environment

TUI hangs / input lag inside tmux when `allow-passthrough on`

Summary

Environment

Symptoms

Repro

What I tried that did not help

Bisect

Captured escape stream (script(1) on macOS, before workaround)

Workaround

Suggested fix (upstream)

References

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Field	Value
`opencode` version	`1.14.25` (Mach-O arm64, Bun-compiled)
Outer terminal	Ghostty (with Ghostty's bundled terminfo on `TERMINFO`)
tmux	`3.6a`
Shell	`nu` (also reproduces from `bash -c 'opencode --pure'`)
OS	macOS, Darwin 25.4.0 (arm64)
TPM plugins	tmux-sensible, tmux-yank, tmux-resurrect, tmux-continuum

Variant	Contents	Result
T1 — full settings minus TPM	default-terminal, terminal-features, terminal-overrides, extended-keys, mouse, mode-keys vi, allow-passthrough on, escape-time 0, history-limit	HANGS
T2 — minus terminal-features/overrides/extended-keys	default-terminal, mouse, mode-keys vi, allow-passthrough on, escape-time 0, history-limit	HANGS
T3 — minus `allow-passthrough on`	default-terminal, mouse, mode-keys vi, escape-time 0, history-limit	WORKS

TUI hangs in tmux after opentui 0.1.103 upgrade (theme detection) #24475

Description

Description

Root Cause

Reproduction

Workaround

Environment

Activity

github-actions commented on Apr 26, 2026

crierr commented on Apr 26, 2026

wallchristopher commented on Apr 26, 2026

thdxr commented on Apr 26, 2026

unifin-chief-engineer commented on Apr 26, 2026

kommander commented on Apr 26, 2026

crierr commented on Apr 27, 2026

MomePP commented on Apr 27, 2026

TUI hangs / input lag inside tmux when allow-passthrough on

Summary

Environment

Symptoms

Repro

What I tried that did not help

Bisect

Captured escape stream (script(1) on macOS, before workaround)

Workaround

Suggested fix (upstream)

References

wallchristopher commented on Apr 27, 2026

github-actions commented on Aug 18, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

TUI hangs / input lag inside tmux when `allow-passthrough on`