Skip to content

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

Closed
Closed
[Critical] CLI hangs on second run (Deadlock) on Linux ARM64 (Proot/Container environments)#7843
Assignees
rekram1-node
Labels
bugSomething isn't workingopentuiThis relates to changes in v1.0, now that opencode uses opentuiperfIndicates a performance issue or need for optimization

Description

@MouatezMo
MouatezMo
opened on Jan 11, 2026

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

Activity

  1. MouatezMo
    added
    bugSomething isn't working
    on Jan 11, 2026
  2. github-actions
    assigned
    rekram1-node
    on Jan 11, 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 Jan 11, 2026

  4. github-actions commented on Jan 11, 2026

    @github-actions
    github-actionsBot
    on Jan 11, 2026 – with GitHub Actions
    Contributor

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

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

  5. llupRisinglll commented on Jan 12, 2026

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

  6. MouatezMo commented on Jan 12, 2026

    @MouatezMo
    MouatezMo
    on Jan 12, 2026
    Author

    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.

  7. rekram1-node commented on Jan 12, 2026

    @rekram1-node
    rekram1-node
    on Jan 12, 2026
    Contributor

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

    Rust? where? haha

  8. MouatezMo commented on Jan 12, 2026

    @MouatezMo
    MouatezMo
    on Jan 12, 2026
    Author

    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.

  9. MouatezMo commented on Feb 6, 2026

    @MouatezMo
    MouatezMo
    on Feb 6, 2026
    Author

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

  10. MouatezMo
    closed this as completedon Feb 6, 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