Termux/Portable Linux 64 Execution Issues + How It Sort Of Works Now

[SlothMecha]

Version

Dev build

Platform

Linux (arm64)

Install channel

GitHub release archive / install.sh / install.ps1

Binary variant

standard

What happened, and what did you expect?

Hi, I've been installing things on my Android phone via Termux with varying degrees of success. While there were some issues getting this to work, I was eventually able to get it most of the way there, as in enough to make my Hermes Agent become extremely useful. Thank you for that, by the way! On to the issues here: it wasn't the cleanest install, and some dependencies to make it work on e.g. Android are missing from the install /instructions. With the help of my very cute AI assistant, I've compiled a list of what went wrong, where and when, and what went right. Feel free to make changes to the build as you see fit!

Android / Termux codebase-memory-mcp installation and verification report
Date: 2026-07-21
Device: Android 13 aarch64
Termux Python: 3.13.13
Hermes Agent: v0.18.2 (2026.7.7.2)
Kernel: Linux localhost 4.19.113-27095354 #1 SMP PREEMPT Tue Mar 4 15:52:06 KST 2025 aarch64 Android

SUMMARY

• Source build from git succeeded.
• Binary installed to ~/.local/bin/codebase-memory-mcp
• Hermes MCP wiring succeeded; 15 tools discovered.
• Indexing is currently blocked on this device by a reproducible crash in the binary during the dump/artifact phase. MCP tool exposure is fine; graph creation is not usable yet.

REPRO STEPS THAT WORKED

1. Prebuilt installer failed

   • Command: curl -fsSL https://raw.githubusercontent.com/DeusData/codebase-memory-mcp/main/install.sh | bash
   • Behavior: downloads codebase-memory-mcp-linux-arm64-portable.tar.gz, extracts, then crashes with "Bad system call" when running the bundled binary.
   • Root cause notes: The downloaded portable asset is an ELF static binary whose exec path uses a syscall/kernel path that Android 13 / kernel 4.19 / Bionic rejects at exec time. ldd does not reveal the issue; the failure is runtime kernel rejection.

2. Source build succeeded

   • git clone --depth=1 https://github.com/DeusData/codebase-memory-mcp.git
   • cd codebase-memory-mcp
   • bash scripts/build.sh
   • Output included: "Built: build/c/codebase-memory-mcp"
   • Resulting binary: ELF shared object, 64-bit LSB arm64, dynamic (/system/bin/linker64), for Android 30, built by NDK r29 (14206865), not stripped
   • Size: 294057640 bytes (~281 MiB)
   • This build runs, unlike the downloaded portable one.

3. Install

   • mkdir -p ~/.local/bin
   • cp build/c/codebase-memory-mcp ~/.local/bin/codebase-memory-mcp
   • chmod 755 ~/.local/bin/codebase-memory-mcp
   • ~/.local/bin/codebase-memory-mcp --version -> codebase-memory-mcp dev

TERMUX PACKAGES REQUIRED THAT ARE NOT IN THE UPSTREAM INSTALLER

• clang
• cmake
• make
• git
• zlib / zlib1g-dev

These were already present here, but the upstream install.sh assumes a normal Linux/macOS host with toolchains available. On a fresh Termux install you must install them first.

HERMES CONFIG CHANGES
File: ~/.hermes/config.yaml
Added under mcp_servers:
codebase-memory:
command: /data/data/com.termux/files/home/.local/bin/codebase-memory-mcp
args: []
connect_timeout: 120.0
timeout: 180

HERMES VERIFICATION RESULTS

• hermes mcp test codebase-memory
  • Connected: yes
  • Tools discovered: 15
• hermes mcp list
  • codebase-memory status: enabled

REPRODUCIBLE CRASH ON INDEXING
A) Real project: /data/data/com.termux/files/home/codebase-memory-mcp

• Result: worker exited nonzero
• Relevant logs:
  • level=info msg=parallel.extract.done nodes=22488 errors=0
  • level=info msg=parallel.resolve.done calls=145181 ...
  • ...
  • level=error msg=pipeline.err phase=dump
  • {"project":"...","status":"error","hint":"Pipeline failed. Check repo_path exists and contains source files. Try mode='fast' for a quicker diagnostic run."}
  • {"status":"error","outcome":"exit_nonzero","hint":"Indexing worker crashed on a file. The crash was contained (the server survived). Re-run to retry; a future release isolates the culprit file."}

B) Tiny synthetic test at ~/tmp-cbm-test/main.py with two classes

• Result: same worker exit_nonzero at phase=dump
• Relevant logs:
  • level=info msg=parallel.extract.done nodes=... errors=data-data-com.termux-files-home-tmp-cbm-test
  • level=error msg=pipeline.err phase=dump
  • {"status":"error","outcome":"exit_nonzero","hint":"Indexing worker crashed on a file. The crash was contained (the server survived). Re-run to retry; a future release isolates the culprit file."}

Because indexing never completes, list_projects cannot behave normally:

• {"error":"cannot read cache directory: /data/data/com.termux/files/home/.cache/codebase-memory-mcp","hint":"Check directory permissions or run index_repository first."}

CONCLUSION FOR USERS

• This MCP server can be wired into Hermes on Android/Termux and the handshake/tool discovery works.
• Do not rely on index_repository from Hermes sessions yet on this environment. The dump/artifact-write path crashes inside the worker in a contained way, but graph data is not persisted.
• If you only use tools that do not require a finished index, those may still work, but most valuable tools depend on indexing.

WHAT THIS IMPLIES FOR UPSTREAM

• The installer's portable linux-arm64 asset is not executable here because it hits a denied syscall at exec time, despite being labeled portable/static.
• The source build does launch, but another fault appears at artifact dump/write. This is the second distinct failure mode on Android/Bionic, separate from the exec failure.
• Crash isolation logs may not always be written to ~/.cache/codebase-memory-mcp/logs/.worker-*.log in run mode, which makes failure triage difficult for end users on Android/Termux.
• Android/Termux is not listed as an explicit supported target in the installer flow; presumably only macOS/Windows/Linux desktops were intended.

FILES CHANGED OR ADDED

• ~/.local/bin/codebase-memory-mcp
• ~/.hermes/config.yaml (added mcp_servers.codebase-memory)
• ~/codebase-memory-mcp/ (source checkout from git clone)
• ~/.cache/codebase-memory-mcp/ (cache directory created, but no usable graph database)

Reproduction

1. https://raw.githubusercontent.com/DeusData/codebase-memory-mcp/main/install.sh - > fails
2. • git clone --depth=1 https://github.com/DeusData/codebase-memory-mcp.git
   • cd codebase-memory-mcp
   • bash scripts/build.sh - > runs, with caveats. See above.
3. Install
   • mkdir -p ~/.local/bin
   • cp build/c/codebase-memory-mcp ~/.local/bin/codebase-memory-mcp
   • chmod 755 ~/.local/bin/codebase-memory-mcp
   • ~/.local/bin/codebase-memory-mcp --version -> codebase-memory-mcp dev - > works

Logs

Diagnostics trajectory (memory / performance / leak issues)

Project scale (if relevant)

No response

Confirmations

• I searched existing issues and this is not a duplicate.
• My reproduction uses shareable code (a dummy snippet or a public OSS repository), not proprietary code.

[DeusData]

This is a genuinely useful report — you did the work of separating "what worked" from "what broke" on a platform nobody here targets, and then wrote it up for the next person. Thank you. Let me give you a real answer on each of the two failure modes, because the first one I can explain exactly.

Failure 1 — "Bad system call" on the portable asset: explained

This is not a mislabelled asset; it is a Bionic incompatibility, and the name portable is misleading in your specific context. The asset is built by the build-linux-portable job (.github/workflows/_build.yml:313-345), whose own comment reads "Fully static Linux binaries (gcc -static on Ubuntu)" — it invokes scripts/build.sh CC=gcc CXX=g++ STATIC=1.

So it is statically linked glibc, not musl. "Portable" there means "runs on any Linux distro regardless of installed shared libraries", which is a glibc-distro claim. On Android, static glibc bypasses Bionic's linker entirely and issues syscalls Android's seccomp filter rejects — that is your SIGSYS / "Bad system call" at exec, and it is exactly why ldd shows nothing useful: the failure is a kernel-level syscall rejection, not a missing library.

Compounding it, install.sh resolves the platform from uname with only Darwin → darwin and Linux → linux (install.sh:111-112), then unconditionally appends -portable for Linux (install.sh:152-156). Termux reports Linux, so it takes the desktop-glibc path and hands you the one binary that cannot run there. Your conclusion that the installer never intended Android is correct, and the code confirms it.

That your NDK r29 source build does run is the corroborating evidence — a Bionic-linked binary works where the static-glibc one cannot.

Failure 2 — the phase=dump crash: not yet explained

This is the more interesting one and I cannot ground it from here, since it reproduces only on Bionic. Two details from your report make it worth chasing rather than dismissing:

• It reproduces on a two-class synthetic file, not just the large repo. That rules out scale, memory pressure and any single pathological source file, and points at the dump/artifact-write path itself.
• Extraction and resolution both complete cleanly (parallel.extract.done nodes=22488 errors=0, parallel.resolve.done calls=145181). So the graph is built; only persistence fails.

You also spotted a real secondary problem: the crash-isolation log is not reliably written to ~/.cache/codebase-memory-mcp/logs/.worker-*.log in run mode, which is what turns this from a diagnosable crash into an opaque one. That gap is worth fixing regardless of whether Android is ever supported, because it degrades triage on every platform.

If you are willing, the single most useful thing you could add is the worker's actual termination signal rather than just exit_nonzero — running the indexing step under catchsegv, or simply capturing echo $? / dmesg around the crash, would distinguish a SIGSYS (another denied syscall, most likely in the file- or mmap-write path) from a SIGSEGV (a genuine bug in the dump code that Android merely exposes first). Those two point at completely different fixes.

On the wider question

Whether Android/Termux becomes a supported target — with the installer changes, a Bionic build variant, and the CI legs that would have to back it — is a scope decision for the maintainer rather than something I should settle in triage, so I am recording it rather than answering it. I have left it at priority/backlog where you filed it.

I would like to keep this issue focused on failure 2, since that is the part with an unknown cause and possible cross-platform relevance. The installer/docs gaps (missing clang, cmake, make, git, zlib prerequisites, and the -portable asset selection on Bionic) are well captured above and can be lifted out of here if and when the platform question is decided.

Thanks again — and glad it is useful to you even in its current half-working state.

[SlothMecha]

Thank you for your kind words and guidance!

Just for the sake of knowledge and illustrating how silly working with Android can be, Termux does technically have access to glibc and funny things like bionilux to run many things an Android phone instance of Linux probably shouldn't, if one really searches for an active repo and contorts their cute little command line interface to get it to run properly, however we initially downloaded, compiled, and ran this repo without doing any of that for everyone's sanity. These resources were omitted again in testing because unless explicitly pointed to, they won't be called upon during most installs/compiles, and frankly, it's a bit too big of an ask to be meaningfully helpful for most people reading this.

Anyway, here is what we found! Hopefully this is of some use. 💖

Dump crash report

Environment: Android 13/ aarch64/ Termux

Binary: ~/.local/bin/codebase-memory-mcp (ELF aarch64, NDK r29, dynamically linked against Bionic libc)

Source: ~/codebase-memory-mcp
Agents: Antigravity CLI (Gemini 3.6 Flash) & Hermes Agent (Step-3.7-Flash) w/ cross-vetting

Reproduction:

codebase-memory-mcp cli index_repository '{"repo_path":"","name":"cbm-termux"}'

After successful parallel.extract.done / parallel.resolve.done, worker exits with:

level=error msg=pipeline.err phase=dump {"status":"error","outcome":"exit_nonzero","signal":0}

Supervisor reap: outcome=exit_nonzero, exit_code=1, signal=0.
No DB file materializes. list_projects -> "cannot read cache directory" until re-run.

ANALYSIS

Historical trigger: the cache directory for the output DB did not exist at dump time. The dump path in src/pipeline/pipeline.c tries to create the parent with cbm_mkdir_p(),
but on Bionic that creation was not taking effect in the observed repro. The writer then opens /.db.tmp.. with O_CREAT|O_TRUNC, which fails with ENOENT if the parent is still missing, and is reported generically as phase=dump with exit 1.

EVIDENCE

Strace shows the exact failure sequence:
openat(.../.cache/codebase-memory-mcp/cbm-termux.db.tmp.<pid>.0x..., O_WRONLY|O_CREAT|O_TRUNC, 0666) = -1 ENOENT (No such file or directory) unlinkat(..., same tmp path, 0) = -1 ENOENT write(2, "level=error msg=pipeline.err phase=dump" ...) exit_group(1)

Reproduction was also reproduced with a nested non-existent CBM_CACHE_DIR, confirming the failure tracks parent-directory existence, not a specific source file.

Prior runs also showed both logs/.worker-.log and response file paths in the logged worker_failed line; their existence in logs should not be taken as evidence the file is readable. Multiple open attempts against the same path returned ENOENT, so those artifacts were reported but never actually created in this environment.

STEPS TAKEN

DUMP SUBSTEP PROFILE

Under CBM_PROFILE=1, the failure falls between:
dump sub=2_build_dump_nodes
dump sub=4_release_gbuf_indexes
with no sub=3_build_dump_edges / sub=6_write_db_finalize emitted. That points directly at cbm_writer_open() or the first DB append, not tree-sitter extraction or LSP resolve.

CBM_PROFILE=1 REPRO

Rationale: Dump phase emits sub-step timings; narrows failing call.
Finding: fails between sub=2_build_dump_nodes and sub=4_release_gbuf_indexes. No sub=3_build_dump_edges / sub=6_write_db_finalize. -> not graph build, not SQLite finalize

STRACE ON FULL REPO

Rationale: see the exact syscall returning error.
Finding:
openat(...cbm-termux.db.tmp.<pid>.0x..., O_WRONLY|O_CREAT|O_TRUNC, 0666) = -1 ENOENT exit_group(1)
No signal kill, clean exit 1 (signal=0). openat ENOENT on temp DB path.

SYNTHETIC NESTED CBM_CACHE_DIR REPRO

Rationale: rule out scale, specific source file, repo_path.
Finding: same phase=dump failure when cache dir does not exist. Confirms parent-dir creation is the issue, not repo content.

cbm_gbuf_dump_to_sqlite() writes to /.db.tmp... The parent directory creation is ineffective on Bionic in the observed repro. When the cache dir (or its logs subdir) is absent, open(O_CREAT|O_TRUNC) returns ENOENT. Worker exits non-zero via _Exit. This path is a clean exit.

NOTES & THOUGHTS

This failure exits non-zero with WIFEXITED, not WIFSIGNALED, distinct from the bugs where fdatasync/mmap/WAL paths blow up under seccomp or SELinux. This run did not signal-kill the worker; it returned 1 after an ignored/insufficient mkdir attempt.

Index_repository / CLI/flows should note that CBM_CACHE_DIR defaults may require the parent to exist, or auto-create it.

The worker log path is logged even when logs/ does not exist. Ensure the log directory is created before tailing it, and tolerate its absence at reap time.
Observable signal: future release should consider emitting term_signal whenever WIFSIGNALED is true, so SIGSYS / SIGSEGV can be triaged without repro.

MINIMAL FIX SUGGESTION FOR ANDROID/TERMUX USERS

In src/pipeline/pipeline.c, make the dump_dir creation failure explicit instead of returning success and then failing:
open(): if (!cbm_mkdir_p(db_dir, CBM_DIR_PERMS)) { cbm_log_error("pipeline.err", "phase", "dump_mkdir", "path", db_dir); return CBM_NOT_FOUND; }
NB: This ONLY prevents the opaque phase=dump exit on missing parent and gives a searchable log key. The runtime fix is a one-line guard and no guarantee of overall increased success or safety while running.