Bash is where most of the work in a terminal actually happens: the aliases in .bashrc, the Ctrl+R history search, the half-hour deploy.sh run, the tail -f you leave open all afternoon. All of that state lives on the computer where bash runs — which is why a fresh SSH login from a phone feels like someone else's shell: new prompt position, no scrollback, and a session that dies when the connection does. CLIAnywhere gives you the session you already have: bash keeps running on your PC, and the iOS, Android or web client attaches to it from anywhere, with history and scrollback intact.
Short Answer
Install the open-source CLIAnywhere daemon on the machine where your bash setup lives, install the app on your phone (or open the web client), and pair them once with an access key. From then on, tapping the PC in the app opens the same persistent bash session that runs on the PC: your .bashrc and aliases apply because the shell never left the host, commands run from the phone land in the same history file, and a dropped connection costs you nothing — the session, its running jobs and its scrollback stay on the PC until you reconnect.
Why This Is Difficult
A bash session is a pile of state that lives in exactly one process, on exactly one machine. The environment variables and shell functions live in the bash process's memory. The scrollback lives in the terminal emulator's window on the host. The history lives in ~/.bash_history — but bash only appends to it when the shell exits cleanly (or when you force it with history -a), and even then history is a list of commands, not the output or the working context.
A conventional remote setup recreates only a shadow of this. Each SSH login from a phone starts a new bash process: the aliases load from .bashrc, but the in-memory state of the session at your desk — variables exported by hand, the current directory, background jobs, the last 500 lines of output — does not come with it. And when the mobile connection drops, the new session receives SIGHUP and is gone, taking its scrollback with it.
You can patch around each symptom — history tricks, log files, multiplexers — but the underlying mismatch stays: remote clients keep trying to recreate a session on the host, when what you actually want is to rejoin the one that already exists. That requires the session to be owned by the host itself, which is the design CLIAnywhere uses.
Common Solutions
Option 1: An SSH client on the phone
A mobile SSH app connecting to an SSH server on your machine is the standard route. It works, and for logging into servers you administer it is the right tool. For using your own workstation's bash it has real costs: the machine needs an SSH server that is reachable from wherever you are (port forwarding, a public IP, or a jump host), keys have to be managed on the phone, and every login is a brand-new shell.
Session state is the recurring pain: the connection drops, the shell gets SIGHUP, scrollback is lost, and background jobs die unless you planned ahead with nohup or disown.
Option 2: bash inside tmux over SSH
Running bash inside tmux on the host fixes most of the session loss: the tmux server holds the shell, survives disconnects, and tmux attach restores windows and scrollback. Add shopt -s histappend and PROMPT_COMMAND='history -a' in .bashrc so multiple shells share history promptly, and the setup is genuinely solid.
What remains is everything around bash: the SSH reachability problem, key management on the phone, and the ergonomics of typing tmux's prefix keys on a touch screen. It is a stack of tools you operate, rather than a single thing that works.
Best for: SSH users who want session persistence and don't mind the setupOption 3: Scripts plus log files
The pragmatic workaround when no remote access exists: start the long job before you leave (./deploy.sh > deploy.log 2>&1 &, or under nohup), then check the log later — from another terminal at home via SSH, or when you are back. Simple, and it keeps the job alive.
But it is one-way: you can read what happened, not act on it. If the script asks a question, hangs on a prompt, or needs to be stopped, a log file does not help — there is no way back into an interactive session that was never interactive remotely.
Best for: fire-and-forget jobs on machines you'll return toOption 4: CLIAnywhere
CLIAnywhere keeps bash where its state is. The daemon on your PC hosts the session; the phone app, the web client, and the desktop all attach to the same shell. Your .bashrc, aliases, functions, PATH and prompt apply because bash is reading them from your home directory on your PC — nothing is configured on the phone at all.
Disconnects become a non-event: the shell keeps running, output keeps accumulating into scrollback, and commands from every device go into the one history file. There is no SSH server to expose, no keys on the phone, and no port forwarding — the connection is peer-to-peer over DTLS where possible, with an encrypted relay as fallback.
Best for: using your own machine's bash from a phone, with zero reconfigurationUsing CLIAnywhere
Install the daemon where your bash setup lives
The machine whose .bashrc you actually use gets the daemon — Linux (desktop UI or headless CLI build) or macOS, from GitHub Releases. Full instructions are in the setup guide. On the phone: Android on Google Play, iOS on the App Store (see the download page), or the Web App in any browser.
Pair once with an access key
Create the access key in the app and link it to the daemon — paste it in, or scan the daemon's QR code. Pairing is a local SPAKE2 exchange; the Security Code is generated on your PC and never uploaded. Each PC you add keeps its own code, and one account can hold several machines.
Open your bash session and use it like bash
Tap the PC in the app and you are in a bash shell on that machine. Ctrl+R finds commands from your existing history; aliases like gs or k work because the shell sourced your .bashrc; tab completion behaves as on the desktop. Start a long script, put the phone away, and reopen the session later from the phone, the web client or the PC — it is the same shell throughout.
| bash as a supported shell | Yes — alongside zsh, fish, sh, cmd, pwsh, powershell |
|---|---|
| Shell runs on the host (.bashrc, aliases, PATH) | Yes — nothing configured on the phone |
| History shared with the desktop session | Yes — same HISTFILE on the host |
| Scrollback preserved across reconnects | Yes |
| Long scripts survive disconnects | Yes |
| Linux / macOS host | Yes (Windows too; Linux has a headless CLI build) |
| iOS / Android / Web client | Yes — see the download page |
| SSH server, port forwarding or public IP required | No |
| Encryption | SPAKE2 key exchange + AES-256-GCM, P2P (DTLS) with encrypted relay (WSS) fallback |
| Open-source daemon | Yes — github.com/CLIAnywhere/clianywhere_daemon |
Example: Watching a Deployment Script From Lunch
Your project has a deploy.sh — it runs the test suite, builds a container, pushes it and restarts the service, printing a stream of output along the way. You start it at your desk at 12:10 in the bash session on your Linux box: ./deploy.sh, foreground, no wrapper.
At 12:15 you leave for lunch. Ten minutes later you open CLIAnywhere on your phone and tap the PC: the script is on the test phase, exactly where it was. You scroll back through the build output — the scrollback belongs to the session, not the desk — and see the warning you missed. Nothing to reattach, nothing that restarted.
The push step hangs on a registry timeout. From the phone you run Ctrl+C, check docker images, and rerun just the push: ./deploy.sh --push-only — an alias-free plain command, but Ctrl+R finds it later on the desktop, because both devices typed into the same history. When you are back at your desk, the terminal window shows the finished deploy, with every line still in scrollback. If the deploy had failed while you were walking, the phone's lock screen would still be a lock screen — the session would simply have been waiting.
Security
Giving a phone a window into your bash session should require strong protection, and it does: the connection is end-to-end encrypted with keys negotiated locally via SPAKE2 (the Security Code never leaves your PC), traffic is AES-256-GCM encrypted, peer-to-peer over DTLS where possible, and the relay only ever sees ciphertext. There is no exposed SSH port to scan. See how CLIAnywhere handles security for details.