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

OpenCode TUI Hangs on Fedora Linux (npm & bun & standalone) #3814

New Issue
Open
opened 2026-02-16 17:41:34 -05:00 by yindo · 6 comments
yindo commented 2026-02-16 17:41:34 -05:00
Owner
Copy Link
Copy Source

Originally created by @nilltadios on GitHub (Dec 23, 2025).

Originally assigned to: @kommander on GitHub.

Description

The interactive Terminal User Interface (TUI) of opencode freezes immediately upon startup on Fedora Linux. This occurs with both the bun installation and the standalone binary.

The process hangs on a futex lock, requiring a SIGTERM to exit.
However, non-interactive commands (opencode run, opencode stats) and opencode serve work correctly.

System Information

  • OS: Fedora Linux (kernel 6.x)
  • CPU: AMD Ryzen 7 7735HS
  • Terminal: xterm / gnome-terminal
  • OpenCode Version: 1.0.193

Logs / Trace

Running strace opencode shows the process hanging on futex calls:

futex(0x..., FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, ...)
sched_yield()
...

Workarounds

  • Use opencode run "query" for single commands.
  • Use opencode serve and connect via the Web UI.
  • opencode attach also fails (likely uses the same TUI code).

Request

Please investigate the TUI rendering or threading logic for compatibility with Fedora/Red Hat systems, particularly on AMD hardware if relevant.

OpenCode version

1.0.193

Steps to reproduce

  1. Install opencode via bun (bun install -g opencode-ai) OR via the standalone script.
  2. Run opencode (interactive mode) in the terminal.
  3. The application displays nothing or hangs immediately.
  4. The process cannot be interrupted easily (sometimes requires kill).

Screenshot and/or share link

Image

Operating System

Fedora 43

Terminal

Cosmic Terminal, and GNOME Terminal

Originally created by @nilltadios on GitHub (Dec 23, 2025). Originally assigned to: @kommander on GitHub. ### Description The interactive Terminal User Interface (TUI) of `opencode` freezes immediately upon startup on Fedora Linux. This occurs with both the `bun` installation and the standalone binary. The process hangs on a `futex` lock, requiring a `SIGTERM` to exit. However, non-interactive commands (`opencode run`, `opencode stats`) and `opencode serve` work correctly. ## System Information - **OS:** Fedora Linux (kernel 6.x) - **CPU:** AMD Ryzen 7 7735HS - **Terminal:** xterm / gnome-terminal - **OpenCode Version:** 1.0.193 ## Logs / Trace Running `strace opencode` shows the process hanging on `futex` calls: ``` futex(0x..., FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, ...) sched_yield() ... ``` ## Workarounds - Use `opencode run "query"` for single commands. - Use `opencode serve` and connect via the Web UI. - `opencode attach` also fails (likely uses the same TUI code). ## Request Please investigate the TUI rendering or threading logic for compatibility with Fedora/Red Hat systems, particularly on AMD hardware if relevant. ### OpenCode version 1.0.193 ### Steps to reproduce 1. Install `opencode` via bun (`bun install -g opencode-ai`) OR via the standalone script. 2. Run `opencode` (interactive mode) in the terminal. 3. The application displays nothing or hangs immediately. 4. The process cannot be interrupted easily (sometimes requires `kill`). ### Screenshot and/or share link <img width="1920" height="1200" alt="Image" src="https://github.com/user-attachments/assets/7eff4b5a-0e8f-40de-a7fd-9adcb0464139" /> ### Operating System Fedora 43 ### Terminal Cosmic Terminal, and GNOME Terminal
yindo added the opentuibug labels 2026-02-16 17:41:34 -05:00
yindo commented 2026-02-16 17:41:34 -05:00
Author
Owner
Copy Link
Copy Source

@github-actions[bot] commented on GitHub (Dec 23, 2025):

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

  • #5361: TUI freezes for ~10 seconds periodically on WSL2 (regression in v1.0.129) - Similar TUI hang/freeze behavior with opentui, though on different OS
  • #6057: Nothing is displayed - Black screen issue on Windows Terminal with OpenCode v1.0.193
  • #4140: black screen when using >1.0.46 - Black screen on startup on macOS with opentui

These issues all involve TUI rendering or responsiveness problems in v1.0+. Your Fedora Linux hang might be related to the opentui library changes that introduced the WSL2 freezing regression in v1.0.129.

Feel free to ignore if your specific case is distinct from these.

@github-actions[bot] commented on GitHub (Dec 23, 2025): This issue might be a duplicate of existing issues. Please check: - #5361: TUI freezes for ~10 seconds periodically on WSL2 (regression in v1.0.129) - Similar TUI hang/freeze behavior with opentui, though on different OS - #6057: Nothing is displayed - Black screen issue on Windows Terminal with OpenCode v1.0.193 - #4140: black screen when using >1.0.46 - Black screen on startup on macOS with opentui These issues all involve TUI rendering or responsiveness problems in v1.0+. Your Fedora Linux hang might be related to the opentui library changes that introduced the WSL2 freezing regression in v1.0.129. Feel free to ignore if your specific case is distinct from these.
yindo commented 2026-02-16 17:41:34 -05:00
Author
Owner
Copy Link
Copy Source

@nilltadios commented on GitHub (Dec 27, 2025):

Additional findings and working containerized workaround:

I did some more investigation and found a working workaround using Podman containers. Here are my findings:

Environment

  • Fedora 43, kernel 6.17.12-300.fc43.x86_64
  • AMD Ryzen 7 7735HS
  • Terminals tested: GNOME Terminal, Cosmic Terminal
  • OpenCode 1.0.203

What I tried

Approach Result
Native install (bun, curl script) Hangs on futex
Distrobox with Alpine Still hangs (shares host kernel)
Raw Podman container with Alpine Works

Key finding

The critical difference is PTY allocation, not the libc implementation (glibc vs musl).

  • Distrobox inherits the host's terminal state → still hangs
  • Podman with -it allocates a fresh pseudoterminal → works

This suggests the issue is in how opentui interacts with the terminal, specifically something about the inherited terminal state on Fedora that causes the futex deadlock.

Working workaround

I created a wrapper script that runs opencode in a Podman container:

#!/bin/bash
# /usr/local/bin/opencode
# Workaround for TUI hang issue on Fedora

USERNS_OPT=""
if [ "$(id -u)" -ne 0 ]; then
    USERNS_OPT="--userns=keep-id"
fi

exec podman run -it --rm \
    --name opencode-session \
    $USERNS_OPT \
    --network=host \
    --security-opt label=disable \
    -v "$HOME:$HOME" \
    -w "${PWD}" \
    -e "HOME=$HOME" \
    -e "TERM=${TERM:-xterm-256color}" \
    localhost/opencode "$@"

With a minimal Alpine-based Containerfile:

FROM docker.io/library/alpine:3.21
RUN apk add --no-cache bash curl git nodejs npm python3
RUN curl -fsSL https://opencode.ai/install | bash \
    && mv /root/.opencode/bin/opencode /usr/local/bin/opencode \
    && chmod 755 /usr/local/bin/opencode
WORKDIR /workspace
ENTRYPOINT ["opencode"]

This gives full functionality with home directory access and host networking.

Hypothesis

The issue might be related to terminal capabilities or stty settings that Fedora's terminals set differently. The fresh PTY in the container starts with a clean state, bypassing whatever initialization causes the deadlock.

It might be worth investigating what terminal attributes opentui reads/sets at startup and whether there's a specific tcgetattr/tcsetattr or termios setting that differs between a fresh PTY and Fedora's terminal emulators.

@nilltadios commented on GitHub (Dec 27, 2025): **Additional findings and working containerized workaround:** I did some more investigation and found a working workaround using Podman containers. Here are my findings: ### Environment - Fedora 43, kernel 6.17.12-300.fc43.x86\_64 - AMD Ryzen 7 7735HS - Terminals tested: GNOME Terminal, Cosmic Terminal - OpenCode 1.0.203 ### What I tried | Approach | Result | |----------|--------| | Native install (bun, curl script) | Hangs on futex | | Distrobox with Alpine | Still hangs (shares host kernel) | | Raw Podman container with Alpine | Works | ### Key finding The critical difference is **PTY allocation**, not the libc implementation (glibc vs musl). - **Distrobox** inherits the host's terminal state → still hangs - **Podman with `-it`** allocates a fresh pseudoterminal → works This suggests the issue is in how opentui interacts with the terminal, specifically something about the inherited terminal state on Fedora that causes the futex deadlock. ### Working workaround I created a wrapper script that runs opencode in a Podman container: ```bash #!/bin/bash # /usr/local/bin/opencode # Workaround for TUI hang issue on Fedora USERNS_OPT="" if [ "$(id -u)" -ne 0 ]; then USERNS_OPT="--userns=keep-id" fi exec podman run -it --rm \ --name opencode-session \ $USERNS_OPT \ --network=host \ --security-opt label=disable \ -v "$HOME:$HOME" \ -w "${PWD}" \ -e "HOME=$HOME" \ -e "TERM=${TERM:-xterm-256color}" \ localhost/opencode "$@" ``` With a minimal Alpine-based Containerfile: ```dockerfile FROM docker.io/library/alpine:3.21 RUN apk add --no-cache bash curl git nodejs npm python3 RUN curl -fsSL https://opencode.ai/install | bash \ && mv /root/.opencode/bin/opencode /usr/local/bin/opencode \ && chmod 755 /usr/local/bin/opencode WORKDIR /workspace ENTRYPOINT ["opencode"] ``` This gives full functionality with home directory access and host networking. ### Hypothesis The issue might be related to terminal capabilities or stty settings that Fedora's terminals set differently. The fresh PTY in the container starts with a clean state, bypassing whatever initialization causes the deadlock. It might be worth investigating what terminal attributes opentui reads/sets at startup and whether there's a specific `tcgetattr`/`tcsetattr` or termios setting that differs between a fresh PTY and Fedora's terminal emulators.
yindo commented 2026-02-16 17:41:34 -05:00
Author
Owner
Copy Link
Copy Source

@nilltadios commented on GitHub (Dec 28, 2025):

Bug: opencode hangs on systems with noexec /tmp

Environment

  • OS: Fedora 43
  • /tmp mounted with noexec (common on hardened Linux systems following CIS benchmarks)

Problem

opencode hangs indefinitely on systems where /tmp is mounted with the noexec option. The same binary works perfectly in containers (where /tmp typically allows exec).

Root Cause

The Bun runtime extracts native helper modules (.so files) to /tmp and attempts to execute them via mmap with PROT_EXEC. When the kernel blocks this due to noexec, the application hangs silently with no error message.

Current Workaround

Users must remove noexec from /tmp, which is a security trade-off:

# For systemd-managed /tmp
sudo mkdir -p /etc/systemd/system/tmp.mount.d
sudo tee /etc/systemd/system/tmp.mount.d/override.conf << 'EOF'
[Mount]
Options=mode=1777,strictatime,nodev,nosuid
EOF

sudo systemctl daemon-reload
sudo mount -o remount,exec /tmp

Feature Request

Please consider adding an environment variable (e.g., OPENCODE_TMPDIR or respecting BUN_TMPDIR) to allow users to specify an alternative temp directory that permits execution. This would support hardened Linux environments without requiring system-wide security changes.

Many enterprise and security-conscious users run with noexec /tmp as a baseline hardening measure.

@nilltadios commented on GitHub (Dec 28, 2025): ### Bug: opencode hangs on systems with `noexec /tmp` #### Environment - OS: Fedora 43 - `/tmp` mounted with `noexec` (common on hardened Linux systems following CIS benchmarks) #### Problem `opencode` hangs indefinitely on systems where `/tmp` is mounted with the `noexec` option. The same binary works perfectly in containers (where `/tmp` typically allows exec). #### Root Cause The Bun runtime extracts native helper modules (`.so` files) to `/tmp` and attempts to execute them via `mmap` with `PROT_EXEC`. When the kernel blocks this due to `noexec`, the application hangs silently with no error message. #### Current Workaround Users must remove `noexec` from `/tmp`, which is a security trade-off: ```bash # For systemd-managed /tmp sudo mkdir -p /etc/systemd/system/tmp.mount.d sudo tee /etc/systemd/system/tmp.mount.d/override.conf << 'EOF' [Mount] Options=mode=1777,strictatime,nodev,nosuid EOF sudo systemctl daemon-reload sudo mount -o remount,exec /tmp ``` #### Feature Request Please consider adding an environment variable (e.g., `OPENCODE_TMPDIR` or respecting `BUN_TMPDIR`) to allow users to specify an alternative temp directory that permits execution. This would support hardened Linux environments without requiring system-wide security changes. Many enterprise and security-conscious users run with `noexec /tmp` as a baseline hardening measure.
yindo commented 2026-02-16 17:41:34 -05:00
Author
Owner
Copy Link
Copy Source

@kabo commented on GitHub (Jan 15, 2026):

Having the same issue, making opencode completely unusable. Would be great if opencode could respect the TMPDIR variable.

@kabo commented on GitHub (Jan 15, 2026): Having the same issue, making opencode completely unusable. Would be great if opencode could respect the `TMPDIR` variable.
yindo commented 2026-02-16 17:41:34 -05:00
Author
Owner
Copy Link
Copy Source

@kabo commented on GitHub (Feb 10, 2026):

Update: With version 1.1.53 this command works for me:

TMPDIR=~/.opencode/tmp BUN_TMPDIR=~/.opencode/tmp opencode
@kabo commented on GitHub (Feb 10, 2026): Update: With version 1.1.53 this command works for me: ``` TMPDIR=~/.opencode/tmp BUN_TMPDIR=~/.opencode/tmp opencode ```
yindo commented 2026-02-16 17:41:35 -05:00
Author
Owner
Copy Link
Copy Source

@MrMarble commented on GitHub (Feb 10, 2026):

Having same issue, none of the workaround fixes it for me.

running strace opencode, the last outputs is

epoll_ctl(17, EPOLL_CTL_ADD, 18, {events=EPOLLIN, data=0x12}) = 0
epoll_ctl(17, EPOLL_CTL_ADD, 20, {events=EPOLLIN, data=0x14}) = 0
epoll_pwait(17, 0x7ffd23ebd740, 1024, -1, NULL, 8) = -1 EINTR (Interrupted system call)
--- SIGWINCH {si_signo=SIGWINCH, si_code=SI_KERNEL} ---
epoll_pwait(17%

I got opencode to launch with OPENCODE_DISABLE_DEFAULT_PLUGINS=true opencode

if I run just opencode and look for running processes, I see opencode add --force --exact --cwd /home/atinocom/.config/cache/opencode opencode-anthropic-auth@0.0.13 so maybe there's some error trying to login

@MrMarble commented on GitHub (Feb 10, 2026): Having same issue, none of the workaround fixes it for me. running `strace opencode`, the last outputs is ```shell epoll_ctl(17, EPOLL_CTL_ADD, 18, {events=EPOLLIN, data=0x12}) = 0 epoll_ctl(17, EPOLL_CTL_ADD, 20, {events=EPOLLIN, data=0x14}) = 0 epoll_pwait(17, 0x7ffd23ebd740, 1024, -1, NULL, 8) = -1 EINTR (Interrupted system call) --- SIGWINCH {si_signo=SIGWINCH, si_code=SI_KERNEL} --- epoll_pwait(17% ``` I got opencode to launch with `OPENCODE_DISABLE_DEFAULT_PLUGINS=true opencode` if I run just `opencode` and look for running processes, I see `opencode add --force --exact --cwd /home/atinocom/.config/cache/opencode opencode-anthropic-auth@0.0.13` so maybe there's some error trying to login
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
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#3814
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?