[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