Hermes Agent on Android with Termux: installation and model configuration

Having an AI agent running on your phone is not a tinkerer's trick: it's a Linux terminal running inside Android, and Termux is that terminal. Hermes Agent has an official package for Termux, configuring models is the exact same work you do on WSL2, and the only thing that changes is where to find the app.

This article does three things: the history of Termux, which explains why the app can no longer be installed from Google Play, and why finding it on F-Droid or Zapstore is the correct procedure; the step-by-step installation with the commands; and the model configuration, with the command you need and the limits that actually exist on a phone.

The history of Termux: a Linux terminal inside Android

Termux was born on May 30, 2015, the work of Swedish developer Fredrik Fornwall. The idea was radically simple: a terminal emulator for Android that installs a minimal base system on first launch, and then lets you install packages with a package manager derived from Debian's.

It is not a virtual machine, and it is not a chroot inside another system. Termux is a Linux environment that runs in userspace directly on top of the Android kernel: same kernel, zero virtualization. Binaries are compiled with the Android NDK, without the FHS directory structure (/etc, /usr, /var do not exist where you would expect them), and the prefix is /data/data/com.termux/files/usr.

This choice is the key to everything else: no root, no extra partitioning, no modified boot. On any phone, without unlocking anything, you have bash, git, python, ssh, clang and over a thousand packages.

The first real problem arrives with Android 10. From November 2020, Google requires apps on the Play Store to target at least API level 29. Under that rule, Android prevents an app from calling exec() on files inside its own home directory — the so-called W^X violation: you cannot execute code from a writable directory.

Termux, to work, does exactly this: it installs binaries in $PREFIX/bin and runs them. The app had declared targetSdkVersion 28 to work around the problem, and under the new Play Store rules it could no longer be updated. The last version published on the Play Store is v0.101; the team explicitly advises moving to F-Droid or GitHub, where this constraint does not exist.

The packages had a second, independent problem: in May 2021 Bintray, which hosted the Termux package repositories, shut down. Termux migrated everything to Hetzner.

In January 2020 support for Android 5 and 6 was dropped: Android 7 is the minimum. In November 2024, Termux received funding from the NLnet Foundation under the NGI Mobifree programme.

Why this history still matters today. If you open the Play Store and search for Termux, you find an app stuck at a version years old. It is not a dead project: it is a project that can no longer go through there. And the version you find on F-Droid is the one that keeps getting updated.

Where to find Termux: F-Droid and Zapstore

F-Droid: the normal route

F-Droid is a catalogue of free software for Android: no account required, no ads, and the client is downloaded as an APK from its website.

Termux is here: https://f-droid.org/en/packages/com.termux/. The package page shows two useful things: the version number and the list of supported architectures.

Version 0.118.3  (1002)  suggested
arm64-v8a  armeabi-v7a  x86  x86_64
Requires Android 7.0 or newer

The suggested version is the stable recommended one; betas are listed above. F-Droid builds the APK itself when it detects a new release on GitHub, so it can take two to seven days: if a new version appears on the project site and is not on F-Droid, that is not a bug.

Two practical notes. First, you do not need to install the F-Droid client to get Termux: from the package page you can download the APK directly. The client is needed to receive update notifications. Second, if you install the APK by hand you will never get notifications: F-Droid itself says so on the package page.

The file is a universal APK of about 108-109 MiB, valid for all architectures. On first launch the base system is downloaded and configured.

Zapstore: the app store built on Nostr

Zapstore (zapstore.dev) is another catalogue of apps for Android, and the difference from F-Droid is why it deserves a mention here: there is no central server deciding what can be installed.

On F-Droid, developers submit code, and F-Droid recompiles it on its own infrastructure, signing it with its own key. It is a precise trust model: you trust F-Droid. On Zapstore, instead, the developer signs the release metadata themselves and publishes it to Nostr relays, according to the NIP-82 event model — which is a draft, not yet in the canonical NIP repository, and which Zapstore implements on its own.

The three event types in play:

This is the same mechanism described in the article Nostr: the protocol that moves control from users to platforms: identity is a key pair, not an account. On Zapstore anyone with a key pair can publish, and the receiver verifies the signature. No account, no gatekeeper.

The Android client is the most mature product of the project, released on GitHub: the current release is 1.1.3, with an attached APK. The client reads from the relays, verifies hash and signing certificate before installation, and uses the trust signals of Nostr's web of trust (who you follow, who follows you, how many zaps) to tell you how trustworthy a publisher is.

Zapstore is not an exclusive substitute for F-Droid: many apps are indexed starting from GitHub releases, or published by the developer themselves with the zsp publishing tool. It is an additional channel.

Termux is indexed there, at zapstore.dev/apps/com.termux, with the same description and icon as the F-Droid page. In Termux's case the card shows the Indexed status: the catalogue knows it, but it is not a verified publisher publishing on its own, so the card does not list signed releases. The F-Droid route remains the most direct for Termux; Zapstore is the right answer if your goal is not to depend on a single catalogue.

Installing the Zapstore client follows the scheme Android imposes on everything outside the Play Store: download the APK from the project site, grant the permission to install from unknown sources once, then open the app. For Zapstore no account is needed, and after installation it is worth updating it from the app when it proposes a new version: staying on a recent build avoids most catalogue and update-notification problems.

Why not the Play Store

Because the Play Store is the closed route, not the discouraged one. The app is stuck at version 0.101, and the development team has no access to the Play Store console where Termux is published, so it cannot even withdraw it: it has explicitly asked users to move elsewhere. On some devices the Play Store has started publishing an updated version built from a different codebase (requires Android 11), but it is not the official channel and the two builds are not interchangeable: if you installed one, installing the other fails because of a different signature.

Installing Termux

An arm64-v8a phone with Android 7 or above. It is worth having a few hundred MB free and a decent connection for the first launch.

pkg update && pkg upgrade
termux-setup-storage

The second command is the one people often skip, which then costs time: it asks for permission to access shared storage, and without that permission Termux cannot see the folders of downloaded files. Termux files live in a private home, and other apps' downloads are in /storage/emulated/0. When you need to work on those files, you mount the link:

ls ~/storage/shared

If you installed Termux from the Play Store and want to move to F-Droid: uninstall that first, because the signatures are different and the update fails with errors like INSTALL_FAILED_UPDATE_INCOMPATIBLE or signatures do not match. The same goes for plugins: Termux:API and the others are separate APKs, and all of them must be removed.

Installing Hermes Agent on Termux

There is something you need to know before starting, because the official documentation says it and it is not a footnote: the Termux package is a second-tier platform, maintained best-effort. Commits on main can break it at any time. The route below is the one that works; it is not covered by the same guarantees as macOS, Windows and Linux.

And there is a second thing, worth reading twice: the official documentation carries the warning "Termux is currently broken". The package does not work at the moment, a fix is on the way, and the steps below may fail or install a package that does not start. The same repo shows the discrepancy: the stable channel does not respond (404 for both the key and the repository), while the canary channel is present and contains a pre-release version.

Route A: APT — the official package

Hermes publishes a signed APT repository for Termux, with two channels under hermes-assets.nousresearch.com/releases/termux/:

This package compiles nothing on the phone: it includes Python, Node.js, npm, uv, ripgrep, ffmpeg and the runtime libraries, with the native wheels already built. It is roughly 173 MB of package, installed without a toolchain. The wheels target Android API 24 (android_24_arm64_v8a), so aarch64 is required.

The steps:

# 1. Repository tools
pkg install curl gnupg

# 2. Public key
mkdir -p "$PREFIX/etc/apt/keyrings"
curl -fsSL https://hermes-assets.nousresearch.com/releases/termux/canary/key.asc \
  -o "$PREFIX/etc/apt/keyrings/hermes-agent.asc"

# 3. Fingerprint verification
gpg --show-keys --with-fingerprint "$PREFIX/etc/apt/keyrings/hermes-agent.asc"

The key fingerprint is:

C572 B5FD D1A2 9CCF A9A9  12B6 840B 0848 E139 156D

If it is different, stop. Do not disable signature verification: the value I found was read from the canary channel, which responds; the documentation cites the same identifier for both channels, because the key is a single one.

# 4. Repository (canary, since stable does not respond)
printf '%s\n' \
  "deb [signed-by=$PREFIX/etc/apt/keyrings/hermes-agent.asc] https://hermes-assets.nousresearch.com/releases/termux/canary hermes-canary main" \
  > "$PREFIX/etc/apt/sources.list.d/hermes-agent.list"

# 5. Installation
pkg update
pkg install hermes-agent

# 6. Verification
hermes --version
hermes doctor

The hermes, hermes-agent and hermes-acp commands are symlinks in $PREFIX/bin and do not require Termux's python or nodejs packages: they use the runtimes contained in the package.

Route via install.sh: the alternative that exists today

There is a second route, and at this moment it is the one most likely to work, because it does not depend on the APT repository:

curl -fsSL https://hermes-agent.nousresearch.com/install.sh | bash

The script recognises Termux on its own: it uses pkg for system packages, creates the virtual environment with python -m venv, exports ANDROID_API_LEVEL for the wheel builds, and puts hermes in $PREFIX/bin so it stays on PATH. It deliberately skips the browser and WhatsApp bootstrap.

A detail that says a lot about the care behind the script: if you run it in an environment where Hermes is already installed via APT, the script refuses and tells you to use pkg install hermes-agent instead. It does not overwrite an installation managed by the package manager.

Updates

If the installation is APT, update with:

pkg update && pkg upgrade hermes-agent

hermes update must not be used: on an installation owned by APT it refuses to modify the package files and prints the package manager command in its place.

To change channel, edit the path and suite in the hermes-agent.list file, then:

pkg update && pkg upgrade hermes-agent

Files and configuration

The package includes Python 3.14 and the TUI, and the wheel closure is core plus acp, not all desktop extras. Updating with APT preserves configuration, sessions, skills and memory.

Configuring access to the models

Model configuration is identical to what you do on WSL2, because it is the same agent. Only the initial command changes.

hermes setup
hermes --tui

The command you need

hermes model

This is the wizard: it adds providers, asks for API keys, runs the OAuth flows and writes the choice. It is the only command that adds a provider.

If you are already inside a session, you can change model with the slash command:

/model openrouter/anthropic/claude-sonnet-4.5

With --global the choice also persists for future sessions. But /model does not add providers: if you do not see it in the picker, exit the session and use hermes model.

Where the configuration goes

~/.hermes/
├── config.yaml     # model, terminal backend, compression
├── .env            # API keys and secrets
├── auth.json       # OAuth credentials
└── sessions/       # sessions

Keys go in .env, the rest in config.yaml. With hermes config set the value lands in the right file on its own: an UPPER_SNAKE name like OPENROUTER_API_KEY goes into .env, dotted keys go into config.yaml.

The fastest way to set up a provider with an API key:

hermes config set OPENROUTER_API_KEY «redacted:sk-…»
hermes config set model.provider openrouter
hermes config set model.default anthropic/claude-sonnet-4.5

The resulting section in config.yaml:

model:
  provider: openrouter
  default: anthropic/claude-sonnet-4.5

A warning that applies on any platform, not just here. If you write the key by hand, check the indentation: YAML uses it for structure, and a misaligned key is not an error you see in the message — it is a provider that does not appear in the picker.

The configuration options

Beyond the main model there are auxiliary models: the job of compressing context, analysing images, summarising pages, generating session titles. Each has its own slot and can be replaced independently. On a phone it is worth keeping two or three configured instead of seven: fewer commands, fewer attempts, less traffic.

If you want to restrict the picker to what you actually use:

model:
  default: anthropic/claude-sonnet-4.5
  provider: openrouter
  picker_providers:
    - openrouter

And if a provider goes down, a fallback chain keeps the session going:

fallback_providers:
  - provider: openrouter
    model: anthropic/claude-sonnet-4.5
  - provider: openrouter
    model: google/gemini-2.5-flash

The gateway

This installation does not use systemd, launchd or Windows Tasks. The gateway must be launched in a Termux session:

hermes gateway run

To keep it in the background:

mkdir -p "${HERMES_HOME:-$HOME/.hermes}/logs"
nohup hermes gateway run >> "${HERMES_HOME:-$HOME/.hermes}/logs/gateway.log" 2>&1 &

An interruption in the middle of a phrase is the typical symptom: Android killed the process. You check the logs and try again with termux-wake-lock active, knowing it is a partial remedy.

What works and what does not on a phone

This is the part that articles on the topic tend to compress into a single line, when it is actually where you decide whether the tool is right for you.

Works: the CLI, the TUI, cron support, PTY and background terminals, the Telegram gateway, MCP, Honcho for memory and ACP.

Not available:

• Docker as a terminal backend: there is no Docker daemon inside Termux.
• The local browser: the package does not include Chromium. The browser tool uses a system chromium if one is on PATH (pkg install chromium, if the repository provides it); without it, browsing is not available and the tool says so.
• Local voice transcription with faster-whisper: it depends on ctranslate2, which does not publish wheels for Android. That is the concrete blocker, not a configuration gap.
• .[all] as an installation extra: not supported on Android.

Android can terminate background processes. Battery optimisation exemptions and termux-wake-lock help, but they do not guarantee persistent operation. The gateway on a phone is best-effort, not a managed service.

There is also a detail of a different nature, coming from Python: on this platform sys.platform is "android". A dependency or a skill protected only for linux is not automatically available.

Conclusion

Termux is the most direct way to have a real Linux environment on Android without root, and its history explains why it is installed from F-Droid or Zapstore and not from the Play Store: Android 10's restriction on exec() closed that channel. Zapstore is more interesting for what it is — a catalogue that signs and publishes on Nostr instead of recompiling on a central infrastructure — than for Termux itself, where F-Droid remains the simplest route.

Hermes Agent is there, with a dedicated package that compiles nothing on the phone. Model configuration is the same as on WSL2. But it is a second-tier platform, the official documentation declares the package broken, and the stable channel of the repository does not respond: anyone starting out must know they are entering territory maintained best-effort, not supported like the desktop platforms.

For a phone, this is not a flaw. It is the exact price of having an agent that runs on the device in your pocket, with the battery and background processes the operating system can always reclaim.

References

• Termux — official page
• Termux — Wikipedia (history, first release date, removal from Play Store)
• Termux on F-Droid
• Termux — GitHub repository
• Zapstore — project site
• Zapstore on Nostr
• Zapstore tok0 — the reference implementation of NIP-82 events
• Zapstore — publishing guide with tok0
• Hermes Agent — installation on Android / Termux
• Hermes Agent — supported platforms matrix
• Hermes Agent — configuring models