anomalyco/opencode
1
0
Fork 0
mirror of https://github.com/anomalyco/opencode.git synced 2026-07-22 02:05:26 -04:00
Code Issues 5.9k Packages Projects Releases 19 Wiki Activity

Random TUI freeze/hang with process continuing in background #8904

New Issue
Open
opened 2026-02-16 18:11:08 -05:00 by yindo · 3 comments
yindo commented 2026-02-16 18:11:08 -05:00
Owner
Copy Link
Copy Source

Originally created by @Fmajor on GitHub (Feb 9, 2026).

Originally assigned to: @kommander on GitHub.

Description

Bug Report

Version

opencode --version
1.1.53

Description

OpenCode TUI randomly freezes during normal operation. The freeze can occur anywhere from a few minutes to several hours after starting, with no discernible pattern or trigger.

Key symptoms:

  • TUI interface becomes completely unresponsive to all keyboard input
  • Closing the terminal reveals the process is still running in the background
  • Must manually kill the process to terminate it
  • After restart, the application works normally until the next random freeze

This issue started occurring frequently after upgrading to v1.1.53

Diagnostic Data

1. strace Analysis (Frozen Process)

When the TUI is frozen, the main process continues executing in a busy-wait loop:

strace: Process 748028 attached
epoll_pwait2(19, [{events=EPOLLIN, data=0x4e6563100b0}], 1024, {tv_sec=29, tv_nsec=1988344}, [], 8) = 1
read(23, "\1\0\0\0\0\0\0\0", 8)         = 8
timerfd_settime(23, 0, {it_interval={tv_sec=1, tv_nsec=0}, it_value={tv_sec=1, tv_nsec=0}}, NULL) = 0
epoll_ctl(19, EPOLL_CTL_ADD, 23, {events=EPOLLIN, data=0x4e6563100b0}) = -1 EEXIST (File exists)
clock_gettime(CLOCK_MONOTONIC_COARSE, {tv_sec=17285, tv_nsec=250951118}) = 0
clock_gettime(CLOCK_MONOTONIC_COARSE, {tv_sec=17285, tv_nsec=250951118}) = 0
clock_gettime(CLOCK_MONOTONIC_COARSE, {tv_sec=17285, tv_nsec=251951130}) = 0
futex(0x7f0502719058, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x7f05027402d8, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x7f05027b835c, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x7f05027ec15c, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x7f05027c0158, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x7f0502808158, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x7f05027e815c, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x7f050271905c, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x7f05027e815c, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x7f05027ec15c, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x7f05027b835c, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x7f050280815c, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x7f05027402dc, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x7f050271905c, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x7f05027c0158, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x7f05027e8158, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x7f0502808158, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x7f05027e815c, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x7f05027ec15c, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x7f05027b835c, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x7f05027402dc, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x7f05027c0158, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x7f050280815c, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x7f05027e8158, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x7f05027ec158, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x7f05027402d8, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x7f05027e815c, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x7f0502719058, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x7f05027b835c, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x7f05027c0158, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x7f050280815c, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x7f05027402dc, FUTEX_WAKE_PRIVATE, 1) = 1
sched_yield()                           = 0
sched_yield()                           = 0
sched_yield()                           = 0
futex(0x7f0502719058, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x7f05027402d8, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x7f05027ec158, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x7f05027b835c, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x7f0502808158, FUTEX_WAKE_PRIVATE, 1) = 1

Analysis:

  • The process is stuck in a tight loop continuously calling futex(FUTEX_WAKE_PRIVATE, ...)
  • Multiple sched_yield() calls indicate the process is trying to yield CPU but remaining in the loop
  • This suggests the UI thread is alive but unable to communicate with the worker thread(s)
  • The timerfd is set to 1-second intervals, indicating some kind of heartbeat or polling mechanism

2. Additional strace Observations (Earlier Capture)

From a different strace session during a freeze:

madvise(0x7f053d7b4000, 28672, MADV_DODUMP) = 0
madvise(0x7f053d7bf000, 4096, MADV_DODUMP) = 0
madvise(0x7f03feed4000, 16384, MADV_DODUMP) = 0
pread64(10, "18994266 299355 8983 15132 0 161"..., 256, 0) = 40
madvise(0x7f03fee68000, 16384, MADV_DODUMP) = 0
madvise(0x7f05ad33d000, 4096, MADV_DODUMP) = 0
madvise(0x7f03fee6c000, 16384, MADV_DODUMP) = 0
madvise(0x7f03fee70000, 16384, MADV_DODUMP) = 0
madvise(0x7f03feef0000, 16384, MADV_DODUMP) = 0
madvise(0x7f03fee78000, 16384, MADV_DODUMP) = 0
madvise(0x7f03feef8000, 16384, MADV_DODUMP) = 0
pread64(10, "18994266 299253 8983 15132 0 161"..., 256, 0) = 40
madvise(0x7f03fee88000, 16384, MADV_DODUMP) = 0
madvise(0x7f03feea0000, 16384, MADV_DODUMP) = 0
madvise(0x7f03feea4000, 16384, MADV_DODUMP) = 0
madvise(0x7f03fef2c000, 16384, MADV_DODUMP) = 0
futex(0x7f05b1fee5d4, FUTEX_WAIT_PRIVATE, 3, NULL) = -1 EAGAIN (Resource temporarily unavailable)
pread64(10, "18994266 299253 8983 15132 0 161"..., 256, 0) = 40

Analysis:

  • pread64(10, ...) is repeatedly reading what appears to be /proc/stat (CPU statistics)
  • Heavy madvise(..., MADV_DODUMP) activity suggests memory management operations, possibly related to garbage collection
  • futex(..., FUTEX_WAIT_PRIVATE) returns EAGAIN, indicating a futex operation failure
  • This pattern suggests the process is stuck in a monitoring/polling loop

3. Application Logs

From ~/.local/share/opencode/log/2026-02-09T150541.log:

Error Pattern 1:

INFO  2026-02-09T15:08:30 +3ms service=llm providerID=openai modelID=gpt-5.3-codex sessionID=[REDACTED] small=false agent=build mode=primary stream
INFO  2026-02-09T15:08:30 +2ms service=provider status=started providerID=openai getSDK
INFO  2026-02-09T15:08:30 +1ms service=provider providerID=openai pkg=@ai-sdk/openai using bundled provider
INFO  2026-02-09T15:08:30 +1ms service=provider status=completed duration=2 providerID=openai getSDK
INFO  2026-02-09T15:08:30 +1ms service=bus type=session.updated publishing
ERROR 2026-02-09T15:08:30 +138ms service=session.processor error=The operation was aborted. stack="abort@[native code]\ncancel@/$bunfs/root/src/cli/cmd/tui/worker.js:134966:25\n@/$bunfs/root/src/cli/cmd/tui/worker.js:198965:25\n@/$bunfs/root/src/cli/cmd/tui/worker.js:198964:17\ndispatch@/$bunfs/root/src/cli/cmd/tui/worker.js:17220:30\ndispatch@/$bunfs/root/src/cli/cmd/tui/worker.js:17204:33\n@/$bunfs/root/src/cli/cmd/tui/worker.js:14796:22\nprocessTicksAndRejections@" process
INFO  2026-02-09T15:08:30 +1ms service=bus type=session.error publishing
INFO  2026-02-09T15:08:30 +1ms service=bus type=session.status publishing
INFO  2026-02-09T15:08:30 +0ms service=bus type=session.idle publishing

Error Pattern 2:

INFO  2026-02-09T15:09:53 +3ms service=session.processor process
INFO  2026-02-09T15:09:53 +0ms service=llm providerID=openai modelID=gpt-5.3-codex sessionID=[REDACTED] small=false agent=build mode=primary stream
INFO  2026-02-09T15:09:53 +1ms service=bus type=message.part.updated publishing
ERROR 2026-02-09T15:09:53 +41ms service=session.processor error=The operation was aborted. stack="abort@[native code]\ncancel@/$bunfs/root/src/cli/cmd/tui/worker.js:134966:25\n@/$bunfs/root/src/cli/cmd/tui/worker.js:99157:10\nnext@/$bunfs/root/src/cli/cmd/tui/worker.js:52:41\n@/$bunfs/root/src/cli/cmd/tui/worker.js:135330:22\nprocessTicksAndRejections@" process
INFO  2026-02-09T15:09:53 +0ms service=bus type=session.error publishing
INFO  2026-02-09T15:09:53 +0ms service=bus type=session.status publishing
INFO  2026-02-09T15:09:53 +0ms service=bus type=session.idle publishing
INFO  2026-02-09T15:09:53 +28ms service=bus type=session.updated publishing
INFO  2026-02-09T15:09:53 +14ms service=bus type=message.updated publishing
INFO  2026-02-09T15:09:53 +1ms service=session.compaction pruning
INFO  2026-02-09T15:09:53 +5ms service=bus type=session.status publishing
INFO  2026-02-09T15:09:53 +0ms service=session.prompt step=0 sessionID=[REDACTED] loop
INFO  2026-02-09T15:09:53 +14ms service=session.prompt sessionID=[REDACTED] cancel

Error Pattern 3:

INFO  2026-02-09T15:11:51 +13ms service=session.processor process
INFO  2026-02-09T15:11:51 +0ms service=llm providerID=openai modelID=gpt-5.3-codex sessionID=[REDACTED] small=false agent=build mode=primary stream
ERROR 2026-02-09T15:11:51 +36ms service=session.processor error=The operation was aborted. stack="abort@[native code]\ncancel@/$bunfs/root/src/cli/cmd/tui/worker.js:134966:25\n@/$bunfs/root/src/cli/cmd/tui/worker.js:99157:10\nnext@/$bunfs/root/src/cli/cmd/tui/worker.js:52:41\n@/$bunfs/root/src/cli/cmd/tui/worker.js:135330:22\nprocessTicksAndRejections@" process

Log Analysis:

  • Multiple occurrences of session.processor error=The operation was aborted
  • Stack traces consistently point to /$bunfs/root/src/cli/cmd/tui/worker.js
  • The error originates from the cancel function in the worker
  • Errors occur during normal LLM streaming operations
  • After the error, session.prompt is cancelled and the session goes to idle state
  • The TUI does not recover gracefully from these abort scenarios

Root Cause Hypothesis

Based on the evidence:

  1. Worker Thread Communication Failure: The repeated futex(FUTEX_WAKE_PRIVATE, ...) calls suggest the main thread is trying to wake up worker threads but failing to establish proper communication.

  2. Abort Signal Not Propagated: When session.processor encounters an abort condition, it appears the signal is not properly propagating to the TUI rendering thread, leaving the UI frozen while the backend continues running.

  3. Busy-Wait After Abort: The strace output shows a classic busy-wait pattern with continuous sched_yield() calls, indicating a spinlock-like condition that never resolves.

  4. Code Location: All stack traces point to /$bunfs/root/src/cli/cmd/tui/worker.js, specifically the cancel function around line 134966.

Environment

  • OS: Linux (Gentoo, kernel 6.6.13-gentoo-x86_64)
  • Node.js: v24.11.1
  • OpenCode: 1.1.53
  • Installation: npm via nvm
  • Shell: zsh

Steps to Reproduce

Unfortunately, I cannot provide reliable steps to reproduce. The issue occurs randomly during normal usage:

  1. Start OpenCode normally
  2. Work on a project (editing files, running agent sessions, etc.)
  3. After an indeterminate period (minutes to hours), the TUI freezes
  4. Keyboard input becomes unresponsive
  5. Terminal can be closed, but process remains running in background

Expected Behavior

When an operation is aborted or encounters an error:

  • The TUI should display an error message to the user
  • The UI should remain responsive
  • The application should recover gracefully or allow the user to restart the session

Actual Behavior

  • TUI freezes completely
  • Process continues running in background
  • User must manually kill the process

Workaround

Currently, the only workaround is to:

  1. Close the frozen terminal
  2. Find and kill the background process: pkill -9 opencode
  3. Restart OpenCode

Additional Notes

  • The issue does not appear to be related to any specific project or file type
  • No particular action (e.g., running commands, editing files) seems to trigger it more than others
  • The frozen process consumes CPU cycles (visible in the busy-wait loop)

Plugins

nothing

OpenCode version

v1.1.53

Steps to reproduce

Unfortunately, I cannot provide reliable steps to reproduce. The issue occurs randomly during normal usage:

Start OpenCode normally
Work on a project (editing files, running agent sessions, etc.)
After an indeterminate period (minutes to hours), the TUI freezes
Keyboard input becomes unresponsive
Terminal can be closed, but process remains running in background

Screenshot and/or share link

No response

Operating System

Linux (Gentoo, kernel 6.6.13-gentoo-x86_64)

Terminal

Alacritty

Originally created by @Fmajor on GitHub (Feb 9, 2026). Originally assigned to: @kommander on GitHub. ### Description ## Bug Report ### Version ``` opencode --version 1.1.53 ``` ### Description OpenCode TUI randomly freezes during normal operation. The freeze can occur anywhere from a few minutes to several hours after starting, with no discernible pattern or trigger. **Key symptoms:** - TUI interface becomes completely unresponsive to all keyboard input - Closing the terminal reveals the process is still running in the background - Must manually kill the process to terminate it - After restart, the application works normally until the next random freeze **This issue started occurring frequently after upgrading to v1.1.53** --- ## Diagnostic Data ### 1. strace Analysis (Frozen Process) When the TUI is frozen, the main process continues executing in a busy-wait loop: ```strace strace: Process 748028 attached epoll_pwait2(19, [{events=EPOLLIN, data=0x4e6563100b0}], 1024, {tv_sec=29, tv_nsec=1988344}, [], 8) = 1 read(23, "\1\0\0\0\0\0\0\0", 8) = 8 timerfd_settime(23, 0, {it_interval={tv_sec=1, tv_nsec=0}, it_value={tv_sec=1, tv_nsec=0}}, NULL) = 0 epoll_ctl(19, EPOLL_CTL_ADD, 23, {events=EPOLLIN, data=0x4e6563100b0}) = -1 EEXIST (File exists) clock_gettime(CLOCK_MONOTONIC_COARSE, {tv_sec=17285, tv_nsec=250951118}) = 0 clock_gettime(CLOCK_MONOTONIC_COARSE, {tv_sec=17285, tv_nsec=250951118}) = 0 clock_gettime(CLOCK_MONOTONIC_COARSE, {tv_sec=17285, tv_nsec=251951130}) = 0 futex(0x7f0502719058, FUTEX_WAKE_PRIVATE, 1) = 1 futex(0x7f05027402d8, FUTEX_WAKE_PRIVATE, 1) = 1 futex(0x7f05027b835c, FUTEX_WAKE_PRIVATE, 1) = 1 futex(0x7f05027ec15c, FUTEX_WAKE_PRIVATE, 1) = 1 futex(0x7f05027c0158, FUTEX_WAKE_PRIVATE, 1) = 1 futex(0x7f0502808158, FUTEX_WAKE_PRIVATE, 1) = 1 futex(0x7f05027e815c, FUTEX_WAKE_PRIVATE, 1) = 1 futex(0x7f050271905c, FUTEX_WAKE_PRIVATE, 1) = 1 futex(0x7f05027e815c, FUTEX_WAKE_PRIVATE, 1) = 1 futex(0x7f05027ec15c, FUTEX_WAKE_PRIVATE, 1) = 1 futex(0x7f05027b835c, FUTEX_WAKE_PRIVATE, 1) = 1 futex(0x7f050280815c, FUTEX_WAKE_PRIVATE, 1) = 1 futex(0x7f05027402dc, FUTEX_WAKE_PRIVATE, 1) = 1 futex(0x7f050271905c, FUTEX_WAKE_PRIVATE, 1) = 1 futex(0x7f05027c0158, FUTEX_WAKE_PRIVATE, 1) = 1 futex(0x7f05027e8158, FUTEX_WAKE_PRIVATE, 1) = 1 futex(0x7f0502808158, FUTEX_WAKE_PRIVATE, 1) = 1 futex(0x7f05027e815c, FUTEX_WAKE_PRIVATE, 1) = 1 futex(0x7f05027ec15c, FUTEX_WAKE_PRIVATE, 1) = 1 futex(0x7f05027b835c, FUTEX_WAKE_PRIVATE, 1) = 1 futex(0x7f05027402dc, FUTEX_WAKE_PRIVATE, 1) = 1 futex(0x7f05027c0158, FUTEX_WAKE_PRIVATE, 1) = 1 futex(0x7f050280815c, FUTEX_WAKE_PRIVATE, 1) = 1 futex(0x7f05027e8158, FUTEX_WAKE_PRIVATE, 1) = 1 futex(0x7f05027ec158, FUTEX_WAKE_PRIVATE, 1) = 1 futex(0x7f05027402d8, FUTEX_WAKE_PRIVATE, 1) = 1 futex(0x7f05027e815c, FUTEX_WAKE_PRIVATE, 1) = 1 futex(0x7f0502719058, FUTEX_WAKE_PRIVATE, 1) = 1 futex(0x7f05027b835c, FUTEX_WAKE_PRIVATE, 1) = 1 futex(0x7f05027c0158, FUTEX_WAKE_PRIVATE, 1) = 1 futex(0x7f050280815c, FUTEX_WAKE_PRIVATE, 1) = 1 futex(0x7f05027402dc, FUTEX_WAKE_PRIVATE, 1) = 1 sched_yield() = 0 sched_yield() = 0 sched_yield() = 0 futex(0x7f0502719058, FUTEX_WAKE_PRIVATE, 1) = 1 futex(0x7f05027402d8, FUTEX_WAKE_PRIVATE, 1) = 1 futex(0x7f05027ec158, FUTEX_WAKE_PRIVATE, 1) = 1 futex(0x7f05027b835c, FUTEX_WAKE_PRIVATE, 1) = 1 futex(0x7f0502808158, FUTEX_WAKE_PRIVATE, 1) = 1 ``` **Analysis:** - The process is stuck in a tight loop continuously calling `futex(FUTEX_WAKE_PRIVATE, ...)` - Multiple `sched_yield()` calls indicate the process is trying to yield CPU but remaining in the loop - This suggests the UI thread is alive but unable to communicate with the worker thread(s) - The timerfd is set to 1-second intervals, indicating some kind of heartbeat or polling mechanism ### 2. Additional strace Observations (Earlier Capture) From a different strace session during a freeze: ```strace madvise(0x7f053d7b4000, 28672, MADV_DODUMP) = 0 madvise(0x7f053d7bf000, 4096, MADV_DODUMP) = 0 madvise(0x7f03feed4000, 16384, MADV_DODUMP) = 0 pread64(10, "18994266 299355 8983 15132 0 161"..., 256, 0) = 40 madvise(0x7f03fee68000, 16384, MADV_DODUMP) = 0 madvise(0x7f05ad33d000, 4096, MADV_DODUMP) = 0 madvise(0x7f03fee6c000, 16384, MADV_DODUMP) = 0 madvise(0x7f03fee70000, 16384, MADV_DODUMP) = 0 madvise(0x7f03feef0000, 16384, MADV_DODUMP) = 0 madvise(0x7f03fee78000, 16384, MADV_DODUMP) = 0 madvise(0x7f03feef8000, 16384, MADV_DODUMP) = 0 pread64(10, "18994266 299253 8983 15132 0 161"..., 256, 0) = 40 madvise(0x7f03fee88000, 16384, MADV_DODUMP) = 0 madvise(0x7f03feea0000, 16384, MADV_DODUMP) = 0 madvise(0x7f03feea4000, 16384, MADV_DODUMP) = 0 madvise(0x7f03fef2c000, 16384, MADV_DODUMP) = 0 futex(0x7f05b1fee5d4, FUTEX_WAIT_PRIVATE, 3, NULL) = -1 EAGAIN (Resource temporarily unavailable) pread64(10, "18994266 299253 8983 15132 0 161"..., 256, 0) = 40 ``` **Analysis:** - `pread64(10, ...)` is repeatedly reading what appears to be `/proc/stat` (CPU statistics) - Heavy `madvise(..., MADV_DODUMP)` activity suggests memory management operations, possibly related to garbage collection - `futex(..., FUTEX_WAIT_PRIVATE)` returns `EAGAIN`, indicating a futex operation failure - This pattern suggests the process is stuck in a monitoring/polling loop ### 3. Application Logs From `~/.local/share/opencode/log/2026-02-09T150541.log`: **Error Pattern 1:** ```log INFO 2026-02-09T15:08:30 +3ms service=llm providerID=openai modelID=gpt-5.3-codex sessionID=[REDACTED] small=false agent=build mode=primary stream INFO 2026-02-09T15:08:30 +2ms service=provider status=started providerID=openai getSDK INFO 2026-02-09T15:08:30 +1ms service=provider providerID=openai pkg=@ai-sdk/openai using bundled provider INFO 2026-02-09T15:08:30 +1ms service=provider status=completed duration=2 providerID=openai getSDK INFO 2026-02-09T15:08:30 +1ms service=bus type=session.updated publishing ERROR 2026-02-09T15:08:30 +138ms service=session.processor error=The operation was aborted. stack="abort@[native code]\ncancel@/$bunfs/root/src/cli/cmd/tui/worker.js:134966:25\n@/$bunfs/root/src/cli/cmd/tui/worker.js:198965:25\n@/$bunfs/root/src/cli/cmd/tui/worker.js:198964:17\ndispatch@/$bunfs/root/src/cli/cmd/tui/worker.js:17220:30\ndispatch@/$bunfs/root/src/cli/cmd/tui/worker.js:17204:33\n@/$bunfs/root/src/cli/cmd/tui/worker.js:14796:22\nprocessTicksAndRejections@" process INFO 2026-02-09T15:08:30 +1ms service=bus type=session.error publishing INFO 2026-02-09T15:08:30 +1ms service=bus type=session.status publishing INFO 2026-02-09T15:08:30 +0ms service=bus type=session.idle publishing ``` **Error Pattern 2:** ```log INFO 2026-02-09T15:09:53 +3ms service=session.processor process INFO 2026-02-09T15:09:53 +0ms service=llm providerID=openai modelID=gpt-5.3-codex sessionID=[REDACTED] small=false agent=build mode=primary stream INFO 2026-02-09T15:09:53 +1ms service=bus type=message.part.updated publishing ERROR 2026-02-09T15:09:53 +41ms service=session.processor error=The operation was aborted. stack="abort@[native code]\ncancel@/$bunfs/root/src/cli/cmd/tui/worker.js:134966:25\n@/$bunfs/root/src/cli/cmd/tui/worker.js:99157:10\nnext@/$bunfs/root/src/cli/cmd/tui/worker.js:52:41\n@/$bunfs/root/src/cli/cmd/tui/worker.js:135330:22\nprocessTicksAndRejections@" process INFO 2026-02-09T15:09:53 +0ms service=bus type=session.error publishing INFO 2026-02-09T15:09:53 +0ms service=bus type=session.status publishing INFO 2026-02-09T15:09:53 +0ms service=bus type=session.idle publishing INFO 2026-02-09T15:09:53 +28ms service=bus type=session.updated publishing INFO 2026-02-09T15:09:53 +14ms service=bus type=message.updated publishing INFO 2026-02-09T15:09:53 +1ms service=session.compaction pruning INFO 2026-02-09T15:09:53 +5ms service=bus type=session.status publishing INFO 2026-02-09T15:09:53 +0ms service=session.prompt step=0 sessionID=[REDACTED] loop INFO 2026-02-09T15:09:53 +14ms service=session.prompt sessionID=[REDACTED] cancel ``` **Error Pattern 3:** ```log INFO 2026-02-09T15:11:51 +13ms service=session.processor process INFO 2026-02-09T15:11:51 +0ms service=llm providerID=openai modelID=gpt-5.3-codex sessionID=[REDACTED] small=false agent=build mode=primary stream ERROR 2026-02-09T15:11:51 +36ms service=session.processor error=The operation was aborted. stack="abort@[native code]\ncancel@/$bunfs/root/src/cli/cmd/tui/worker.js:134966:25\n@/$bunfs/root/src/cli/cmd/tui/worker.js:99157:10\nnext@/$bunfs/root/src/cli/cmd/tui/worker.js:52:41\n@/$bunfs/root/src/cli/cmd/tui/worker.js:135330:22\nprocessTicksAndRejections@" process ``` **Log Analysis:** - Multiple occurrences of `session.processor error=The operation was aborted` - Stack traces consistently point to `/$bunfs/root/src/cli/cmd/tui/worker.js` - The error originates from the `cancel` function in the worker - Errors occur during normal LLM streaming operations - After the error, `session.prompt` is cancelled and the session goes to `idle` state - The TUI does not recover gracefully from these abort scenarios --- ## Root Cause Hypothesis Based on the evidence: 1. **Worker Thread Communication Failure**: The repeated `futex(FUTEX_WAKE_PRIVATE, ...)` calls suggest the main thread is trying to wake up worker threads but failing to establish proper communication. 2. **Abort Signal Not Propagated**: When `session.processor` encounters an abort condition, it appears the signal is not properly propagating to the TUI rendering thread, leaving the UI frozen while the backend continues running. 3. **Busy-Wait After Abort**: The strace output shows a classic busy-wait pattern with continuous `sched_yield()` calls, indicating a spinlock-like condition that never resolves. 4. **Code Location**: All stack traces point to `/$bunfs/root/src/cli/cmd/tui/worker.js`, specifically the `cancel` function around line 134966. --- ## Environment - **OS**: Linux (Gentoo, kernel 6.6.13-gentoo-x86_64) - **Node.js**: v24.11.1 - **OpenCode**: 1.1.53 - **Installation**: npm via nvm - **Shell**: zsh --- ## Steps to Reproduce Unfortunately, I cannot provide reliable steps to reproduce. The issue occurs randomly during normal usage: 1. Start OpenCode normally 2. Work on a project (editing files, running agent sessions, etc.) 3. After an indeterminate period (minutes to hours), the TUI freezes 4. Keyboard input becomes unresponsive 5. Terminal can be closed, but process remains running in background --- ## Expected Behavior When an operation is aborted or encounters an error: - The TUI should display an error message to the user - The UI should remain responsive - The application should recover gracefully or allow the user to restart the session ## Actual Behavior - TUI freezes completely - Process continues running in background - User must manually kill the process --- ## Workaround Currently, the only workaround is to: 1. Close the frozen terminal 2. Find and kill the background process: `pkill -9 opencode` 3. Restart OpenCode --- ## Additional Notes - The issue does not appear to be related to any specific project or file type - No particular action (e.g., running commands, editing files) seems to trigger it more than others - The frozen process consumes CPU cycles (visible in the busy-wait loop) --- ### Plugins nothing ### OpenCode version v1.1.53 ### Steps to reproduce Unfortunately, I cannot provide reliable steps to reproduce. The issue occurs randomly during normal usage: Start OpenCode normally Work on a project (editing files, running agent sessions, etc.) After an indeterminate period (minutes to hours), the TUI freezes Keyboard input becomes unresponsive Terminal can be closed, but process remains running in background ### Screenshot and/or share link _No response_ ### Operating System Linux (Gentoo, kernel 6.6.13-gentoo-x86_64) ### Terminal Alacritty
yindo added the opentuibugperf labels 2026-02-16 18:11:08 -05:00
yindo commented 2026-02-16 18:11:08 -05:00
Author
Owner
Copy Link
Copy Source

@github-actions[bot] commented on GitHub (Feb 9, 2026):

This issue might be a duplicate of existing issues. Please check:

  • #11119: High CPU usage (100% single core) during TUI rendering — Shows identical strace patterns with futex() busy-wait loops and worker thread communication issues
  • #11145: TUI freezes for 8-9 seconds in WSL2 with ble.sh — Reports similar random TUI freezes that started around the same version period
  • #12763: OpenCode v1.1.53 randomly crashes during usage on Windows — Also v1.1.53 specific, suggests a regression in this version
  • #9003: main agent hangs because of subagent (explore) — Reports agent/thread hanging issues
  • #6172: High CPU usage (100%+) during LLM streaming in long sessions — Related performance issue with futex and thread communication

All share the common thread of:

  • Random freezes/hangs without user trigger
  • Futex-based busy-wait loops in strace output
  • Worker thread communication failures
  • Multiple issues specifically in v1.1.53

Feel free to ignore if none of these address your specific case.

@github-actions[bot] commented on GitHub (Feb 9, 2026): This issue might be a duplicate of existing issues. Please check: - #11119: High CPU usage (100% single core) during TUI rendering — Shows identical strace patterns with futex() busy-wait loops and worker thread communication issues - #11145: TUI freezes for 8-9 seconds in WSL2 with ble.sh — Reports similar random TUI freezes that started around the same version period - #12763: OpenCode v1.1.53 randomly crashes during usage on Windows — Also v1.1.53 specific, suggests a regression in this version - #9003: main agent hangs because of subagent (explore) — Reports agent/thread hanging issues - #6172: High CPU usage (100%+) during LLM streaming in long sessions — Related performance issue with futex and thread communication All share the common thread of: - Random freezes/hangs without user trigger - Futex-based busy-wait loops in strace output - Worker thread communication failures - Multiple issues specifically in v1.1.53 Feel free to ignore if none of these address your specific case.
yindo commented 2026-02-16 18:11:08 -05:00
Author
Owner
Copy Link
Copy Source

@nullism commented on GitHub (Feb 9, 2026):

I'm also seeing a freeze where it seems completely unresponsive, but for me it lasts a few seconds and the input must have been buffered as I'll eventually see my text input appear. I have no issues with any other TUI, but then again this might be the only TS TUI I've used and maybe that's just how they are?

@nullism commented on GitHub (Feb 9, 2026): I'm also seeing a freeze where it seems completely unresponsive, but for me it lasts a few seconds and the input must have been buffered as I'll eventually see my text input appear. I have no issues with any other TUI, but then again this might be the only TS TUI I've used and maybe that's just how they are?
yindo commented 2026-02-16 18:11:08 -05:00
Author
Owner
Copy Link
Copy Source

@scottsus commented on GitHub (Feb 9, 2026):

seeing this too in opencode version 1.1.50. usually happens after the first assistant message, and sometimes resolves after a few seconds, but other times never resolves

@scottsus commented on GitHub (Feb 9, 2026): seeing this too in opencode version `1.1.50`. usually happens after the first assistant message, and sometimes resolves after a few seconds, but other times never resolves
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
acp
bad
bug
discussion
docs
documentation
enhancement
extension
good first issue
growth
help-wanted
mcp
model-problem
needs:compliance
nix
opentui
perf
pull-request
Mirrored from GitHub Pull Request
 tui
web
windows
zen
No Label bug opentui perf
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
yindo
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: anomalyco/opencode#8904
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?