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

[MouatezMo]

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

[github-actions]

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

• [Bug] Opencode crashes on second run in Termux/Proot distro #3143: [Bug] Opencode crashes on second run in Termux/Proot distro - Very similar symptom of crashes/hangs on second run specifically in Proot environments
• OpenCode crashes with "Aborted" on Termux/Debian on second attempt, [object ErrorEvent] #7472: OpenCode crashes with "Aborted" on Termux/Debian on second attempt - Same pattern of first run succeeding, second run failing in Proot/chroot environments
• Opencode Hangs when used as CLI tool #5888: Opencode Hangs when used as CLI tool - Related CLI hanging issue
• OpenCode TUI Hangs on Fedora Linux (npm & bun & standalone) #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.

[llupRisinglll]

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

[MouatezMo]

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.

[rekram1-node]

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

Rust? where? haha

[MouatezMo]

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.