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

[Critical] CLI hangs on second run (Deadlock) on Linux ARM64 (Proot/Container environments) #4767

New Issue
Closed
opened 2026-02-16 17:45:21 -05:00 by yindo · 6 comments
yindo commented 2026-02-16 17:45:21 -05:00
Owner
Copy Link
Copy Source

Originally created by @MouatezMo on GitHub (Jan 11, 2026).

Originally assigned to: @rekram1-node on GitHub.

Description

Critical Deadlock on ARM64 Proot Environments

I have spent the last 3 days debugging a critical issue where the CLI becomes completely unusable after the very first successful run.

I have tested this across 3 different fresh environments on aarch64:

  1. Ubuntu Jammy (Proot)
  2. Debian Bookworm (Proot)
  3. Ubuntu

The Behavior:

  • On a fresh OS install, opencode runs perfectly.
  • Once I exit (regardless of method), any subsequent attempt to run the tool results in a silent hang (deadlock).
  • The cursor blinks, but the TUI never renders. DEBUG=* yields zero output on the second run, suggesting the process hangs at the very earliest initialization stage.

Why this is critical:
Unlike typical lock file issues, wiping the data directories and reinstalling the tool does NOT resolve the hang. It behaves as if the first run leaves a persistent zombie state, shared memory corruption, or a renderer lock that Proot cannot clear, effectively "burning" the environment 😔

I suspect this is related to how the new Rust-based TUI handles cleanup on ARM64/Containerized systems. Please investigate the cleanup/exit routines for ARM64.

Plugins

No response

OpenCode version

1.1.13 & 1.1.12

Steps to reproduce

  1. Setup a fresh Linux ARM64 environment (Proot or Chroot).
  2. Install OpenCode (curl).
  3. Run opencode -> Works perfectly (Auth & TUI load).
  4. Exit the session cleanly (using /exit or Ctrl+C).
  5. Run opencode again.
  6. Result: The CLI hangs indefinitely (blinking cursor).
  7. Troubleshooting attempt: Fully wiping ~/.local/share/opencode and ~/.config/opencode and reinstalling the tool DOES NOT fix the issue. The environment seems permanently "tainted" after the first run 💔

Screenshot and/or share link

No response

Operating System

Linux aarch64 (Debian Bookworm & Ubuntu Jammy running via Proot)

Terminal

Termux / xterm-256color

Originally created by @MouatezMo on GitHub (Jan 11, 2026). Originally assigned to: @rekram1-node on GitHub. ### Description ### Critical Deadlock on ARM64 Proot Environments I have spent the last **3 days** debugging a critical issue where the CLI becomes completely unusable after the very first successful run. I have tested this across **3 different fresh environments** on aarch64: 1. Ubuntu Jammy (Proot) 2. Debian Bookworm (Proot) 3. Ubuntu **The Behavior:** - On a fresh OS install, `opencode` runs perfectly. - Once I exit (regardless of method), any subsequent attempt to run the tool results in a **silent hang (deadlock)**. - The cursor blinks, but the TUI never renders. `DEBUG=*` yields zero output on the second run, suggesting the process hangs at the very earliest initialization stage. **Why this is critical:** Unlike typical lock file issues, **wiping the data directories and reinstalling the tool does NOT resolve the hang.** It behaves as if the first run leaves a persistent zombie state, shared memory corruption, or a renderer lock that Proot cannot clear, effectively "burning" the environment 😔 I suspect this is related to how the new Rust-based TUI handles cleanup on ARM64/Containerized systems. Please investigate the cleanup/exit routines for ARM64. ### Plugins _No response_ ### OpenCode version 1.1.13 & 1.1.12 ### Steps to reproduce 1. Setup a fresh Linux ARM64 environment (Proot or Chroot). 2. Install OpenCode (curl). 3. Run `opencode` -> Works perfectly (Auth & TUI load). 4. Exit the session cleanly (using `/exit` or `Ctrl+C`). 5. Run `opencode` again. 6. **Result:** The CLI hangs indefinitely (blinking cursor). 7. **Troubleshooting attempt:** Fully wiping `~/.local/share/opencode` and `~/.config/opencode` and reinstalling the tool DOES NOT fix the issue. The environment seems permanently "tainted" after the first run 💔 ### Screenshot and/or share link _No response_ ### Operating System Linux aarch64 (Debian Bookworm & Ubuntu Jammy running via Proot) ### Terminal Termux / xterm-256color
yindo added the opentuibugperf labels 2026-02-16 17:45:21 -05:00
yindo closed this issue 2026-02-16 17:45:21 -05:00
yindo commented 2026-02-16 17:45:21 -05:00
Author
Owner
Copy Link
Copy Source

@github-actions[bot] commented on GitHub (Jan 11, 2026):

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

  • #3143: [Bug] Opencode crashes on second run in Termux/Proot distro - Very similar symptom of crashes/hangs on second run specifically in Proot environments
  • #7472: OpenCode crashes with "Aborted" on Termux/Debian on second attempt - Same pattern of first run succeeding, second run failing in Proot/chroot environments
  • #5888: Opencode Hangs when used as CLI tool - Related CLI hanging issue
  • #6080: OpenCode TUI Hangs on Fedora Linux - Similar TUI freezing/hanging issues on Linux with futex locks

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

@github-actions[bot] commented on GitHub (Jan 11, 2026): This issue might be a duplicate of existing issues. Please check: - #3143: [Bug] Opencode crashes on second run in Termux/Proot distro - Very similar symptom of crashes/hangs on second run specifically in Proot environments - #7472: OpenCode crashes with "Aborted" on Termux/Debian on second attempt - Same pattern of first run succeeding, second run failing in Proot/chroot environments - #5888: Opencode Hangs when used as CLI tool - Related CLI hanging issue - #6080: OpenCode TUI Hangs on Fedora Linux - Similar TUI freezing/hanging issues on Linux with futex locks Feel free to ignore if none of these address your specific case.
yindo commented 2026-02-16 17:45:21 -05:00
Author
Owner
Copy Link
Copy Source

@llupRisinglll commented on GitHub (Jan 12, 2026):

Hi, I also encountered this on my machine, Arch Linux x86_64.

I encounter this bug after my opencode auto-updated into v1.1.13/1.1.14 where it tries to use its own binary for bun add commands, but the binary doesn't support that. Additionally, bun itself hangs when trying to install opencode-anthropic-auth and opencode-copilot-auth packages.

Workaround

Pre-install the required packages using npm before opencode starts.

1. Disable auto-update

Add to ~/.config/opencode/opencode.jsonc:

{
  "autoupdate": false
}

Why: If auto-update is enabled, opencode will upgrade itself on startup, which triggers the broken bun add calls again and overwrites the pre-installed packages we set up below.

2. Create launcher script

Save to ~/.local/bin/opencode-launcher:

#!/bin/bash
# Opencode launcher - pre-installs packages with npm since bun hangs

CACHE_DIR="$HOME/.cache/opencode"
CONFIG_DIR="$HOME/.config/opencode"

# Pre-install auth plugins to cache (only if missing)
if [ ! -d "$CACHE_DIR/node_modules/opencode-anthropic-auth" ] || [ ! -d "$CACHE_DIR/node_modules/opencode-copilot-auth" ]; then
    mkdir -p "$CACHE_DIR"
    cd "$CACHE_DIR"
    [ ! -f package.json ] && echo '{}' > package.json
    npm install opencode-anthropic-auth@0.0.8 opencode-copilot-auth@0.0.12 --save-exact --silent 2>/dev/null
fi

# Install plugin to config dir (only if missing)
if [ ! -d "$CONFIG_DIR/node_modules/@opencode-ai" ]; then
    mkdir -p "$CONFIG_DIR"
    cd "$CONFIG_DIR"
    [ ! -f package.json ] && echo '{}' > package.json
    npm install @opencode-ai/plugin@1.1.13 --save-exact --silent 2>/dev/null
fi

# Run opencode (adjust path if needed)
exec "$(dirname "$(readlink -f "$(which opencode)")")/../node_modules/opencode-linux-x64/bin/opencode" "$@"

Then:

chmod +x ~/.local/bin/opencode-launcher

3. Use the launcher

opencode-launcher

Or add alias to .bashrc/.zshrc:

alias opencode='opencode-launcher'

Environment: Arch Linux x86_64, kernel 6.18, opencode 1.1.14/1.1.13

@llupRisinglll commented on GitHub (Jan 12, 2026): Hi, I also encountered this on my machine, Arch Linux x86_64. I encounter this bug after my `opencode` auto-updated into `v1.1.13/1.1.14` where it tries to use its own binary for `bun add` commands, but the binary doesn't support that. Additionally, bun itself hangs when trying to install `opencode-anthropic-auth` and `opencode-copilot-auth` packages. ## Workaround Pre-install the required packages using npm before opencode starts. ### 1. Disable auto-update Add to `~/.config/opencode/opencode.jsonc`: ```json { "autoupdate": false } ``` **Why:** If auto-update is enabled, opencode will upgrade itself on startup, which triggers the broken `bun add` calls again and overwrites the pre-installed packages we set up below. ### 2. Create launcher script Save to `~/.local/bin/opencode-launcher`: ```bash #!/bin/bash # Opencode launcher - pre-installs packages with npm since bun hangs CACHE_DIR="$HOME/.cache/opencode" CONFIG_DIR="$HOME/.config/opencode" # Pre-install auth plugins to cache (only if missing) if [ ! -d "$CACHE_DIR/node_modules/opencode-anthropic-auth" ] || [ ! -d "$CACHE_DIR/node_modules/opencode-copilot-auth" ]; then mkdir -p "$CACHE_DIR" cd "$CACHE_DIR" [ ! -f package.json ] && echo '{}' > package.json npm install opencode-anthropic-auth@0.0.8 opencode-copilot-auth@0.0.12 --save-exact --silent 2>/dev/null fi # Install plugin to config dir (only if missing) if [ ! -d "$CONFIG_DIR/node_modules/@opencode-ai" ]; then mkdir -p "$CONFIG_DIR" cd "$CONFIG_DIR" [ ! -f package.json ] && echo '{}' > package.json npm install @opencode-ai/plugin@1.1.13 --save-exact --silent 2>/dev/null fi # Run opencode (adjust path if needed) exec "$(dirname "$(readlink -f "$(which opencode)")")/../node_modules/opencode-linux-x64/bin/opencode" "$@" ``` Then: ```bash chmod +x ~/.local/bin/opencode-launcher ``` ### 3. Use the launcher ```bash opencode-launcher ``` Or add alias to `.bashrc`/`.zshrc`: ```bash alias opencode='opencode-launcher' ``` --- **Environment:** Arch Linux x86_64, kernel 6.18, opencode 1.1.14/1.1.13
yindo commented 2026-02-16 17:45:21 -05:00
Author
Owner
Copy Link
Copy Source

@MouatezMo commented on GitHub (Jan 12, 2026):

Thanks! This workaround fixed the first run (plugins installation deadlock). However, on ARM64/Proot, the CLI still hangs on the 2nd run. It seems like a separate issue related to process cleanup or file locking on ARM architectures. I'm digging into the source code now.

@MouatezMo commented on GitHub (Jan 12, 2026): Thanks! This workaround fixed the first run (plugins installation deadlock). However, on ARM64/Proot, the CLI still hangs on the 2nd run. It seems like a separate issue related to process cleanup or file locking on ARM architectures. I'm digging into the source code now.
yindo commented 2026-02-16 17:45:21 -05:00
Author
Owner
Copy Link
Copy Source

@rekram1-node commented on GitHub (Jan 12, 2026):

I suspect this is related to how the new Rust-based TUI

Rust? where? haha

@rekram1-node commented on GitHub (Jan 12, 2026): > I suspect this is related to how the new Rust-based TUI Rust? where? haha
yindo commented 2026-02-16 17:45:21 -05:00
Author
Owner
Copy Link
Copy Source

@MouatezMo commented on GitHub (Jan 12, 2026):

Haha, my bad! The TUI felt so snappy on the first run I assumed it was Rust-based/Ratatui under the hood. I stand corrected.

Terminology aside, the deadlock issue on the second run is very real on ARM64/Proot. Since it's Node-based, maybe it's a lingering event loop or a file lock that bun/node isn't clearing properly in this environment? Would love your insight on where the cleanup logic lives.

@MouatezMo commented on GitHub (Jan 12, 2026): Haha, my bad! The TUI felt so snappy on the first run I assumed it was Rust-based/Ratatui under the hood. I stand corrected. Terminology aside, the deadlock issue on the **_second run_** is very real on ARM64/Proot. Since it's Node-based, maybe it's a lingering event loop or a file lock that bun/node isn't clearing properly in this environment? Would love your insight on where the cleanup logic lives.
yindo commented 2026-02-16 17:45:21 -05:00
Author
Owner
Copy Link
Copy Source

@MouatezMo commented on GitHub (Feb 6, 2026):

Thanks to myself 🙏, after a long time I found the problem and solved it

@MouatezMo commented on GitHub (Feb 6, 2026): Thanks to myself 🙏, after a long time I found the problem and solved it
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#4767
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?