Skip to content

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

Closed as not planned
Closed as not planned
Random TUI freeze/hang with process continuing in background#12834
Assignees
kommander
Labels
bugSomething isn't workingopentuiThis relates to changes in v1.0, now that opencode uses opentuiperfIndicates a performance issue or need for optimization

Description

@Fmajor
Fmajor
opened on Feb 9, 2026

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

Activity

  1. Fmajor
    added
    bugSomething isn't working
    on Feb 9, 2026
  2. github-actions
    assigned
    kommander
    on Feb 9, 2026
  3. github-actions
    added
    opentuiThis relates to changes in v1.0, now that opencode uses opentui
    perfIndicates a performance issue or need for optimization
    on Feb 9, 2026

  4. github-actions commented on Feb 9, 2026

    @github-actions
    github-actionsBot
    on Feb 9, 2026 – with GitHub Actions
    Contributor

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

    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.

  5. nullism commented on Feb 9, 2026

    @nullism
    nullism
    on 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?

  6. scottsus commented on Feb 9, 2026

    @scottsus
    scottsus
    on 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

  7. jon23d commented on Feb 19, 2026

    @jon23d
    jon23d
    on Feb 19, 2026

    I'm here to plus one this. It comes out of nowhere

  8. m0n203 commented on Mar 2, 2026

    @m0n203
    m0n203
    on Mar 2, 2026

    seeing this freeze too in opencode version 1.2.15
    also the terminal is wired after normal exit, seems opencode doesn't properly restore the terminal

  9. aviral-agarwal commented on Mar 3, 2026

    @aviral-agarwal
    aviral-agarwal
    on Mar 3, 2026

    +1
    opencode version 1.2.15 on wsl (windows)
    keeps hanging while writing prompts and processing as well

  10. github-actions commented on May 3, 2026

    @github-actions
    github-actionsBot
    on May 3, 2026 – with GitHub Actions
    Contributor

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

  11. github-actions
    closed this as not plannedon May 3, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

bugSomething isn't workingopentuiThis relates to changes in v1.0, now that opencode uses opentuiperfIndicates a performance issue or need for optimization

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions