Repository navigation
Description
Summary
Since v1.17.0, the TUI hangs on a black screen at boot and never renders. It emits the terminal-capability query sequence and then freezes silently — the backend/logger never even starts. v1.16.2 is the last working version on my machine; v1.17.0 is the first broken one.
This is not terminal-specific, not plugin-related, and not fixable via any documented env var (details below). Looks like a regression in the OpenTUI boot path.
Related but different: #14433 (closed) is about missing plugin dependencies; my case reproduces with --pure (no plugins at all).
Environment
- OS: Zorin OS 18.1 (Ubuntu 24.04 "noble" base), kernel 6.17.0-35
- Session: Wayland
- Terminals tested: GNOME Terminal 3.52 / VTE 0.76.0 and Ghostty v1.3.1 (snap) — both hang
- Node v25.8.1, npm 11.11.0, glibc 2.39
- Install method:
npm i -g opencode-ai
Steps to reproduce
npm i -g [email protected](or any 1.17.x)- Run
opencodein any project, in any terminal - → black screen, frozen, no keyboard response, no error
Expected vs actual
- Expected: TUI renders the prompt UI (as 1.16.2 does)
- Actual: black screen; the process is alive (sleeping in
ep_poll, ~18 threads, ~260 MB RSS, no child process) but never renders and never logs anything
Bisection
| Version | Result |
|---|---|
| 1.16.0 | renders ✓ |
| 1.16.2 | renders ✓ (last good) |
| 1.17.0 | hangs ✗ (first bad) |
| 1.17.6 / 1.17.7 | hangs ✗ |
Tested with a non-responding pty (timeout 8 script -qec "opencode" /tmp/x.raw </dev/null): 1.16.x renders the full UI even when the pty answers no queries; 1.17.x only emits the queries and stops. The same hang reproduces in real GNOME Terminal and real Ghostty.
What I ruled out
- Terminal: hangs in both GNOME Terminal (VTE) and Ghostty (implements the kitty protocols) → not just "terminal doesn't answer a query"
- Plugins:
opencode --pure(no plugins) also hangs - Env vars: tried all of
OPENTUI_NOTIFICATIONS,OPENTUI_NOTIFICATION_PROTOCOL,OPENTUI_GRAPHICS,OPENTUI_FORCE_WCWIDTH,OPENTUI_FORCE_EXPLICIT_WIDTH,OPENTUI_FORCE_UNICODE,OPENTUI_FORCE_NOZWJ,OPENCODE_TERMINAL, andTERM=xterm— all still hang - DB / state: backend runs fine via
opencode run(headless) andopencode serve; only the TUI hangs
Diagnostic detail
With --print-logs --log-level DEBUG, stderr stays empty and ~/.local/share/opencode/log/opencode.log is not written — the hang happens before logging initializes. The only bytes the TUI emits before freezing are the capability queries:
]10;? ]11;? [>0q [?1016$p [?2027$p [?2031$p [?1004$p [?2004$p [?2026$p ]99;i=opentui-notifications:p=? ]1337;Capabilities ]66;w=1; ]66;s=2; [>4;1m ]4;0;?
Workaround
Pin to 1.16.2 and disable auto-update:
npm i -g [email protected]
# opencode.json: "autoupdate": falseHappy to provide an strace/thread dump if useful.
Activity
github-actions commentedon Jun 15, 2026
This issue might be a duplicate of existing issues. Please check:
waitForThemeModeblocking on unanswered OSC sequences, which may be related to the same boot-hang you're seeing since v1.17.0.gschambers commentedon Jun 16, 2026
Same issue on macOS ARM64. Adding a second bisect point:
On macOS the regression window is 1.17.0 → 1.17.1 (narrower than the Ubuntu bisect, which may be a platform difference or the same root cause manifesting slightly differently).
sampleof the hung process shows ~99.6% inkevent64(macOS equivalent ofepoll_wait) — same pattern of event loop waiting for an event that never arrives.simonklee commentedon Jun 25, 2026
See #33905 (comment) for a bit more context on how this can happen.
github-actions commentedon Aug 25, 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.