Termux-OS: a menu-driven shell and colour setup script for Termux

What Termux-OS actually changes on your Android phone

Termux-OS is a menu-driven theme and shell customization tool for Termux, and the project describes it as focused on improving usability and appearance while keeping setup simple and automated. The repository itself is almost empty of code: the top level holds a LICENSE, the README, an os.sh script and an.object/ directory.

That single script is the product. It runs in Termux, which gives it access to a real Linux userland on an Android device, and it edits the configuration files your shell reads at startup. The documentation lists where those files are: the zsh config at `~/.zshrc`, the bash config at `~/.bashrc`, the fish config at `~/.config/fish/config.fish`, and Termux properties for the colour and font settings that Termux itself reads.

So the mechanism is straightforward and worth stating plainly, because it determines both the value and the risk. There is no daemon, no package format, no profile abstraction. The script writes text into files, and the effect appears the next time the shell starts.

The feature set covers shell choice, appearance and one security add-on. You get zsh, fish and bash support, extra Termux keys, a custom username banner, syntax highlighting and auto-suggestions across the three shells, and five curated colour schemes named Default (Gunmetal Neon), Dracula, Nord, Monokai and Solarized Dark. The most recent release listed for the repository is v3.5, tagged Termux-OS v3.5 - The Security Update on 2026-01-17, and the last push was on 2026-07-04.

The project is GPL-3.0 licensed and is written in Bash.

Installing it takes one clone and one script run

Installation is three commands:

git clone https://github.com/h4ck3r0/Termux-os
cd Termux-os
bash os.sh

There is no package to install and no dependency list to satisfy, which is a fair sign of what this is. The script is designed to run inside Termux on the device, where the shell and Termux are already present.

After running `bash os.sh` you are presented with an interactive menu, and the documented flow is four steps. The main menu displays all available options. You select your shell, choosing between Zsh, Fish or Bash. You then customise the setup by picking a theme, colours and any additional features. Finally you apply the changes, and the documentation is explicit that you restart Termux to see them.

That last step is the mechanism again. Nothing is patched live; the script edits files and the new shell reads them. If a change does not appear, the cause is nearly always that the old shell was still running when the file was written, or that the file was written but the shell you are in is not the shell you configured.

Two supporting resources are linked for people who want more than the menu summary. There is an installation video and a detailed guide on the author's site at h4ck3r.me, and the project's own feature descriptions are written to be read alongside them.

The menu itself has seven entries: install zsh theme, install fish theme, install bash theme, apply color theme, setup Cyber Lock, custom username banner, and exit. The shell entries are separate rather than a single shell picker, which means the colour theme and the Cyber Lock are independent of which shell you install.

How the shell customisation differs across zsh, fish and bash

The three shells are not treated the same way, and the differences are the interesting part of the project.

Zsh is the fullest path. Its documented features are auto-completion, plugin support and advanced theming, with syntax highlighting, auto-suggestions and history search included as plugins. That is the natural fit for a Termux setup, because zsh is what most Termux power users install first, and plugin support is what a plugin-based theme is built around.

Fish is native. Its documented features are a user-friendly shell, built-in auto-suggestions and native syntax highlighting, with no plugin layer involved, because fish provides both features itself. The practical consequence is that a fish install should be less fragile than a zsh one, since there is nothing to fetch and nothing to fail to load.

Bash is the newest addition in the list of highlights, and it is powered by the `ble.sh` line editor. The documented features are real-time syntax highlighting and intelligent command suggestions, and the install path is option 3 in the menu followed by the prompts. This is the one case where the tool adds a third-party component rather than using what the shell ships with, and it is the case most likely to behave differently from a plain bash install, because the behaviour comes from a line editor that has to be loaded in the rc file.

The menu order also hints at the intended default. Zsh is option 1, fish option 2 and bash option 3, which reads as a preference order rather than an alphabetical one.

One thing the documentation does not cover is what happens to a shell rc file that already has your own configuration in it. The list of configuration files is given, but no merge or backup behaviour is described, so it is worth reading os.sh before you run it against a device whose shell setup you care about.

The Cyber Lock feature and why SHA-256 alone is not enough

Cyber Lock is the security feature, and the v3.5 release title calls it out as the security update. The behaviour is described in detail.

It is a login gate on the terminal. You select option 5 from the main menu, enter a password and confirm it, and the lock is activated on your next session. On every shell startup the gate asks for the password, and if the password is failed 3 times the session auto-closes. The access keys are hashed using SHA-256 rather than stored in plaintext in the rc files, and the highlight list phrases this as comparing SHA-256 hashes instead of plaintext keys in rc files.

Removing it works the same way in reverse: return to the main menu, select option 5 again, choose the remove or disable option, and confirm your current password.

Now the weakness, because this is the part to think about before you switch it on. A plain SHA-256 hash of a password is a fast, unsalted hash. Fast means an attacker who obtains the stored hash can try billions of candidate passwords per second, and unsalted means every identical password produces an identical hash, so one cracked hash can be reused against other accounts. A login gate is a speed bump for a person holding your phone in their hand, and it is not a defence against someone who can read the file where the hash lives.

That file is a shell startup file, which means it is read on every shell start and is in the path of anything that runs commands in your session. The better construction for a password gate is a slow, salted KDF such as bcrypt, scrypt or Argon2, where the salt and the work factor are stored alongside the hash. A single shell script doing SHA-256 comparison cannot do that without a dependency, which is the trade-off the project has made in exchange for the script having no external requirements.

There is also a narrower point. The gate protects the terminal, not the device. It does not encrypt the filesystem, and it does not stop anyone who can read your Termux data directory directly or who can log in before the shell starts.

The banner, the extra keys and the colour themes

The cosmetic pieces are the bulk of what the tool does, and they are simple.

The Custom Username Banner option adds a personalised ASCII banner to the terminal. You pick option 6, enter your desired username or text, choose an ASCII art style, and the banner appears on every new session. Since it is written into the shell rc file, it renders before your prompt does, which is why it works the same way in zsh, fish and bash without per-shell configuration.

The Extra Termux Keys feature covers the Termux key row, the strip of extra keys Termux draws on screen, where the volume keys and other hardware keys get remapped to things like the Escape key or function keys. That mapping lives in Termux properties rather than in a shell file, which is why the documentation lists Termux properties separately from the three rc paths.

The colour themes are the newest group, described as curated Termux colour schemes with five options: Default (Gunmetal Neon), Dracula, Nord, Monokai and Solarized Dark. Applying one goes through option 4 in the main menu, you pick a number from the list, and the theme is applied immediately to your Termux properties. Even so, the documentation says to exit and reopen Termux to see the full effect, since the terminal renders the properties it read at start.

Applying a colour scheme and installing a shell theme are separate operations on separate files. That is worth noting because the visual result you end up with depends on both, and the menu lets you change one without touching the other.

Where Termux-OS is the wrong choice

The first limit is that it is a script that rewrites your shell configuration. It is not a package with a manifest, an uninstaller, or a record of what it changed. The documentation does not describe a backup of the rc files it edits, and it does not describe an uninstall path for the themes themselves, only for Cyber Lock. If a theme misbehaves, your recovery is manual, which is a real cost on a phone where you may not have another shell handy.

The second limit is that it targets one environment. Everything here assumes Termux on Android, and the colour work in particular is written against Termux properties, which have no equivalent in a desktop terminal emulator. A macOS or Linux user gets a script that edits rc files for a shell they may already have configured, with no terminal theming to show for it.

The third limit is the plugin and dependency surface. The zsh path pulls in plugins, the bash path needs `ble.sh`, and neither is described in terms of what gets fetched or from where. A script that installs a shell theme by downloading components into your home directory is doing supply chain work that the project description does not spell out, and the same is true of the Cyber Lock code that ends up in your rc file.

The fourth limit is the security feature, discussed above. A lock on a shared or semi-shared device might be a reasonable nudge. As protection for anything on the device, an unsalted fast hash in a startup file is thin.

Compare that with configuring the shell by hand. Editing `~/.zshrc` yourself costs a little more time and gives you exactly what you want with nothing hidden, and a hand-written `ble.sh` or plugin setup is one you can audit line by line. The difference in approach is that Termux-OS automates the tedium of a first-time setup and a fresh Termux install, and it charges for that with a script you did not write writing files you did not read.

Licence, maintenance state and what to check before you install

Termux-OS is released under GPL-3.0, with the LICENSE file in the repository root and the project's badge declaring the same. The practical implication for a script like this is that if you modify os.sh and distribute your version, you have to pass those changes on under the same terms, and a script that runs with your privileges deserves a read before you run it rather than after.

The maintenance picture is modest. The repository's most recent release is v3.5 from 2026-01-17, and the last push was on 2026-07-04. It is not archived, so the tree is still there, but the version tag and the tree are several months apart and the topic tags on the project include termux-hacking and termux-styling, which tells you what the author considers the use case.

The homepage is h4ck3r.me, and the project links a how-to-install guide there and an installation video, so the project's own documentation lives partly outside the repository.

What to check before you install is short and specific. Read os.sh, because it is the whole product and it is the only file that runs on your device. Back up the shell rc file for the shell you are about to configure, since the documentation does not promise one for you. If you are on zsh, check what the plugin step fetches. And if you plan to enable Cyber Lock, find where the hash is written, then treat that file as the secret, because a fast unsalted hash is cheap to attack and the file is on the path of every shell start.

If what you want is a themed terminal with working autocompletion and nothing else, this does that in one script run, and the Cyber Lock option is the one to leave off.

Editorial conclusion

Termux-OS fits an Android user on Termux who wants a themed, autocomplete-enabled shell in a few menu clicks and does not want to hand-edit rc files. It does not fit someone who treats the Cyber Lock as real protection, because a single unsalted SHA-256 hash stored in a shell startup file is an offline target, and it does not fit a device where you cannot accept a script rewriting your shell configuration. Before you run it, read os.sh rather than trusting the menu, back up ~/.zshrc or ~/.bashrc first, and if you enable the lock, check where the hash is written and treat that file as the secret it effectively is.

Frequently asked questions

Official sources

1. h4ck3r0/Termux-os on GitHub
2. License: GPL-3.0
3. Project website
4. README
5. Releases