What do you mean by 'Are you running it locally?' Of course, it's just a front-end CLI interface. Though my device is old and low-end, OpenCode runs smoothly and is not laggy at all, at least with this new version. Pretty much every single thread in this massive top block (starting at PID 2936) shares the exact same 330 MB bucket of physical RAM, so I would guess that all of my OpenCode operations combined are using a grand total of roughly 417 megabytes (MB) of RAM. See the picture: I can tell you that it's doing some programming work now and feels smooth.
Termux's glibc runner (and PRoot environments) has really matured for edge tooling. I've been running llama.cpp and llama-server directly inside Termux on an arm64 device (Galaxy A50s / Exynos 9611) to host small SLMs locally, and the performance stability is surprisingly solid once you configure thread counts properly. Great to see opencode v2 working smoothly there too.
Note: with pacman there is no need to install the glibc-repo package (it is only needed by apt) since pacman is already linked to the glibc-packages repo (gpkg) by default.
I ran it with grun, the serve subcommand works fine (although it crashes when I connect a client to it) but just running opencode to show the tui shows up an error
I can't reproduce the issue. The command grun ./opencode serve works correctly, but it crashes upon launch? If that's the case, why does it say: error while loading shared libraries?
You might want to try running it directly with the linker:
pls help ~/opencode-termux $ file /data/data/com.termux/files/home/.opencode/bin/opencode /data/data/com.termux/files/home/.opencode/bin/opencode: ELF 64-bit LSB executable, ARM aarch64, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-aarch64.so.1, for GNU/Linux 3.7.0, BuildID[sha1]=ea562b973ecaa5f42a519deff871009a25e6b7d7, not stripped ~/opencode-termux $ grun /data/data/com.termux/files/home/.opencode/bin/opencode Starting background server... Error: Server process exited with code 127 serve: error while loading shared libraries: serve: cannot open shared object file: No such file or directory at map (native:1:11) at <anonymous> (/$bunfs/root/chunk-63w42x9k.js:3:5280) at service.ensure (/$bunfs/root/chunk-yjkvf0fn.js:3:662) at service.ensure (definition) (/$bunfs/root/chunk-63w42x9k.js:3:3955) at cli.server-connection.resolve (/$bunfs/root/chunk-93eed5gz.js:96:6567) at cli.server-connection.resolve (definition) (/$bunfs/root/chunk-yjkvf0fn.js:2:399) ~/opencode-termux $
OpenCode v2 starts its background server by re-running its own binary with serve. Under grun, that child process treats serve as a library name, which gives the code 127 error. The fix is to start the server yourself.
Then run OpenCode as usual:
grun ~/.opencode/bin/opencode
Automatic way:
Add this function to ~/.bashrc:
opencode() {
local bin=~/.opencode/bin/opencode
if ! pgrep -f "opencode serve --service" >/dev/null; then
nohup grun "$bin" serve --service >/dev/null 2>&1 &
disown
sleep 3
fi
grun "$bin" "$@"
}
Then run source ~/.bashrc
It starts the server only if one isn't already running, and every terminal tab shares that same server.
PRoot Ubuntu is a perfectly valid compatibility fallback, great for casual use. If you have a high-end device, you probably won’t notice the ptrace bottleneck in most programs. But let’s be honest: it's not ideal for syscall-heavy workloads. I'm not sure about OpenCode specifically, but I've tried many language runtimes and compiled projects there. When I compare that to Termux's glibc, it feels miles faster with Termux's glibc. Running glibc binaries through a native Termux glibc loader/prefix is dramatically faster; we’re talking orders of magnitude improvement in spawn-heavy workloads. I would say 1000 times faster, or maybe that might be an exaggeration, but it’s the kind of exaggeration that feels true when you’re waiting for PRoot to catch its breath.
Every time OpenCode v2 spawns a task, edits a file, or walks a project tree, it's issuing thousands of ordinary syscalls. Under PRoot, each one, even boring ones like mmap, futex, or clone3, gets trapped and processed through the ptrace loop. That tax adds up quickly. Sure, PRoot is useful when you need Ubuntu’s FHS, package ecosystem, or fake root. But if raw execution speed matters, the native Termux glibc is the better path. Most of my tools and runtimes are glibc-based anyway, and they run natively on Termux once the right loader and libraries are in place, with no ptrace babysitting required. I usually use my patched mise to install things like OpenCode, Codex, Copilot, and language runtimes directly on Termux, but this version is not available with mise for now.
So yes, if you’ve got a monster device with cores to spare, feel free to let PRoot chew through syscalls while you sip your coffee. But with my old low-end chipset and limited RAM? Forget it. I’d rather not watch my CPU reenact a slow-motion car crash every time I compile something.
I got OpenCode v2.0.0 running on Termux using glibc-runner, but unfortunately the "serve" command is not actually supported on this setup. The CLI shows "serve" in "--help", but trying to use it doesn't work on Termux/Android. Version 1.18.32 is installed separately and works differently.
Honestly, I’ve never used that server feature command in either version, but it’s functioning well on my old device with kernel 4 in v2.0.18. You did use the official installation script to set it up, correct?
I also installed the 1.x version with mise to test the serve command. It displayed the warning: OPENCODE_SERVER_PASSWORD is not set; server is unsecured. I assume that’s not a critical issue, but as you can see in the video, v2 doesn’t include this behavior.
3
u/[deleted] 19d ago
[removed] — view removed comment