Termly CLI mirrors a terminal coding agent to your phone, with the relay server hardcoded
Mobile companion for Claude Code, Gemini CLI & OpenCode. Encrypted, remote
At a glance
- What is it?
- Termly CLI runs a coding assistant in a pseudo terminal on your machine and relays the session so you can drive it from a phone or tablet, with AES-256-GCM encryption and a key exchange you can verify by fingerprint. What the readme settles and what the package contradicts are both worth reading: the server URL cannot be changed, and the published package ships no test suite.
- Who is it for?
- Termly CLI fits someone who starts long agent sessions on a laptop and wants to check or steer them from a phone, since the session model is a pty per terminal rather than a reimplementation of any agent. It does not fit anyone who needs to relay through their own infrastructure, because the server URL is hardcoded per environment and explicitly cannot be changed.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 74 days ago.
- What is it written in?
- Mainly JavaScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on October 4, 2026, and from our analysis. They are not legal advice.
Editorial analysis
The relay URL is hardcoded per environment and cannot be changed
There are three environments, and each one is bound to a specific server.
Production uses the published package, the `termly` command, and a secure websocket endpoint on the vendor's own domain. Development uses a separate package and a separate command against a development endpoint for beta testers. Local means running from source with an environment variable set, pointing at a websocket endpoint on port 3000 on your own machine.
The constraint is stated plainly: the server URLs are hardcoded per environment and cannot be changed by users.
That is the single most important operational fact in the documentation, and it sits oddly next to the zero-knowledge claim. The server never sees your unencrypted data, which is true, and your plaintext still passes through a server you do not operate. Both statements can be simultaneously honest, and the combination is worth holding in mind.
It also rules out the usual mitigation. A team that would otherwise put a relay behind its own network boundary cannot, and a user who wants to audit the path has no configuration point to intervene at.
The local mode exists for developing the client itself, and it is marked as for developers only.
Encryption has its own specification, and the fingerprint is the user interface
The encryption claim is precise about primitives, and the repository documents them in separate files.
The scheme is AES-256-GCM for the data with a Diffie-Hellman exchange at 2048 bits for the key, and the feature list adds fingerprint verification. That combination is the usual shape for an end-to-end encrypted relay: symmetric encryption for the session, an ephemeral exchange to agree the key, and a fingerprint so both ends can confirm they derived the same key without a trusted third party.
The fingerprint is where it becomes a user-facing feature rather than a claim. The quick list command is documented as a quick list of active sessions with encryption fingerprints for verification, so checking that the phone is talking to the right machine is a command you can run rather than a setting you hope is on.
At the repository root there are two documents that matter for anyone evaluating the claim: a crypto specification and a communication protocol document, alongside a security policy and a Windows debugging note.
That layout is the strongest signal available here. A product advertising end-to-end encryption usually does not publish the protocol; this one does, in files a reviewer can read before installing anything.
The pty dependency is aliased to a fork, which is why nothing compiles
The reason installation is fast is a dependency substitution, and it is visible in the manifest.
A terminal-based agent needs a pseudo terminal, and the usual package for that in Node is one with native bindings that need a toolchain on every platform. Termly instead depends on the pty package under an alias pointing at a fork that ships prebuilt binaries for all platforms.
The result is a set of guarantees the readme lists as absolutes: no Visual Studio required on Windows, no Xcode command line tools on macOS, no build-essential on Linux, and no compilation step. Installation is stated as typically completing in between ten and thirty seconds.
The only requirement is Node 18 or newer, and the supported platforms are called out as macOS on both Intel and Apple Silicon, Linux on x64 and ARM64, and Windows 10 or newer on x64 and ARM64.
The trade-off is that you are trusting a specific fork for the component that sees all of your terminal input and output. The alias makes that substitution legible rather than hidden, which is the right way to do it, and it is the reason there is no build troubleshooting section for macOS or Linux users.
The published package ships a placeholder test script
The manifest's test script is the one npm generates when a project has no tests.
It echoes that no test is specified and exits with a non-zero status, which means `npm test` on the published package fails by design rather than by accident.
That is worth stating plainly because of what the tool claims to support. The readme advertises more than twenty interactive terminal agents, from Claude Code and Copilot CLI to Aider and OpenCode, each with its own interactive output format, and the mechanism for handling those is a pseudo terminal plus whatever terminal capability detection the tool does.
There is no automated coverage of that surface in the package, so each new agent listed in a release note is an integration that only a user discovers by trying it.
The surrounding process documents are more developed than that: a release checklist, a communication protocol specification, a crypto specification, a migration note for the move to ES modules, a Windows debugging guide, and a separate development manifest for the beta package. So the project has invested in process rather than in tests, which is a choice a reader can accept or not, but it should be a choice made knowingly.
Each session is one terminal, one connection, and one phone
The session model is deliberately small, and it is what makes multiple sessions safe.
You start a session from the project directory with the start command, and a second session is a second terminal in a second directory. Each session runs an independent instance of the AI tool, opens its own websocket connection to the relay, and can connect one mobile device.
So the isolation is per terminal rather than per tool installation. Two sessions running the same agent do not share state, and the documentation implies the mobile side pairs with one of them.
Management is three commands: status to show sessions, list for a quick view with the encryption fingerprints, and stop with either a session identifier or a flag to stop all of them. The session identifiers look like short hyphenated tokens, which is what you would paste from the status output.
Resuming is a property of the underlying agent rather than of the relay. The example that continues a previous Claude Code session passes a continue flag through to the agent, which is how context is restored after a restart. The 1.9.3 release handled an expired pairing error returned by the server on reconnect, which tells you pairing is a server-side token with a lifetime rather than a permanent key.
Interactive terminal support is the hard requirement, and TUI tools are the stress test
The compatibility rule is stated once and applies to everything: it works with any terminal-based AI tool that supports interactive TTY mode.
That single requirement is what the tool list is really about, and the release history shows which tools push on it hardest. Terminal user interface support arrived in 1.7 together with OpenCode integration, and 1.9 added an enhanced TUI mode alongside two more agents.
Two entries in the list are marked as having full TUI support: OpenCode, described as a terminal-based agent with language server integration, and Kilo Code CLI, described as an agentic engineering tool with more than five hundred models and a parallel mode. Both are the kind of program that repaints the screen constantly, so a relay that assumes line-oriented output will break on them.
The list also includes the official tools from the major vendors, which is the part that changes with each vendor release: Claude Code, GitHub Copilot CLI, Cursor CLI, Amazon Q Developer, Gemini CLI, Grok CLI, Codex CLI, and Qwen Code, the last of which arrived in 1.9.5 and is noted as optimised for a particular model family.
Below those sit open source tools, including local-model runners, which matters because those work with no vendor account at all.
The tool count differs between the readme and the package description
Two numbers are given for the same thing, and they do not match.
The readme says the tool supports more than twenty-three interactive terminal-based coding assistants, and then splits them into official tools from major companies, popular open source tools, and experimental or future support.
The package description in the manifest says something different: control Claude, Aider, Copilot, and 19 or more tools from your phone.
The gap is four tools, and the readme's own list has also drifted from the manifest description, which still names only three specific agents. A package description is what users see in search results and in their dependency list, so a count that disagrees with the documentation is a small but real accuracy problem.
The experimental category is worth reading for the project's own view of its limits. A named agent is listed as when released, and anything else terminal-based is covered by the general rule.
Auto-detection is what makes a long list workable in practice: the tool finds what is installed, and the start command has a flag to turn that off when you want to be explicit. There are also commands to list what it believes is available, detect what is actually installed, and show information about one tool.
Two packages, two commands, and a codebase mid-migration
Distribution is split between a public package and a beta one, and the split is visible in the repository.
The public package installs the `termly` command and points at the production relay:
npm install -g @termly-dev/cliThe beta package installs a different command name against a different relay. The development package installs `termly-dev` and points at the development relay, and it is described as for beta testers and development rather than for everyday use.
There is a second manifest in the repository for the development build, alongside the release one, which is how the two package identities are maintained without duplicating the source.
The documentation also gives the source path for local work: clone the repository, install dependencies, and run the CLI entry point directly with the local environment set. That entry point is the same file the installed command runs.
One migration is in progress and has its own document at the root. The project is moving to ES modules, and the packaging shows signs of both worlds: the manifest declares a CommonJS-style main entry while the scripts invoke the entry file with plain Node.
The release history is the other thing to read, because it is unusually granular for a small project. It records a stable release with session management and encryption, Windows output deduplication and shell optimisation, prebuilt binaries, TUI mode and OpenCode, two agent integrations, an enhanced TUI mode, reconnect handling, and most recently a new vendor tool plus eight dependency alerts patched.
Editorial conclusion
Termly CLI fits someone who starts long agent sessions on a laptop and wants to check or steer them from a phone, since the session model is a pty per terminal rather than a reimplementation of any agent. It does not fit anyone who needs to relay through their own infrastructure, because the server URL is hardcoded per environment and explicitly cannot be changed. Before installing, note that the npm package publishes a placeholder test script that exits non-zero, so nothing in the tool surface is covered by an automated suite, and check the crypto specification yourself rather than relying on the feature list.
Frequently asked questions
How do I install Termly CLI?
Run npm install -g @termly-dev/cli, which registers the termly command. Node 18 or newer is the only requirement, because the pseudo terminal dependency is aliased to a fork with prebuilt binaries for macOS, Linux, and Windows, so no compiler toolchain is needed and installation is stated as ten to thirty seconds.
Can I run my own Termly server?
No. There are three environments, production, development, and local, and the documentation states that the server URLs are hardcoded per environment and cannot be changed by users. The server is described as zero-knowledge in the sense that it never sees unencrypted data, but the relay itself is the vendor's.
Which AI coding tools does Termly CLI support?
The readme says more than twenty-three interactive terminal-based assistants, from Claude Code, Copilot CLI, Cursor CLI, Gemini CLI, Codex CLI, and Qwen Code through Aider, OpenCode, Kilo Code CLI, Pi Coding Agent, Continue CLI, OpenHands, and others, while the package description says nineteen or more. The real requirement is interactive TTY mode.
How does Termly CLI handle multiple sessions?
One session per terminal in a project directory. Each has an independent AI tool instance and its own websocket connection, and each can connect one mobile device. You manage them with a status command, a list command that also shows encryption fingerprints, and a stop command that takes a session identifier or stops all of them.
How is the Termly CLI connection encrypted?
With AES-256-GCM for the data and a Diffie-Hellman exchange at 2048 bits for the key, plus fingerprint verification. The quick list command prints those fingerprints so the pairing can be checked, and the repository carries a crypto specification and a communication protocol document describing it in detail.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/termly-dev-termly-cli)