Termly CLI: Mirror Claude Code and 22 Other Terminal AI Tools to Your Phone

The problem Termly CLI solves, and who it is aimed at

Interactive terminal AI tools assume you are sitting in front of the machine running them. Claude Code, Aider, OpenCode and the other assistants in this category hold a live TTY session: you type a prompt, the agent streams output, and the process stays attached to that terminal. Step away from the laptop and the session is effectively frozen. You can leave it running, but you cannot answer the next clarifying question or approve a file edit.

Termly CLI targets that gap. The package description puts it plainly: "Mirror your AI coding sessions to mobile - control Claude, Aider, Copilot, and 19+ tools from your phone". The intended user is a developer who already works in a terminal-based assistant and wants a second, remote control surface for it. It is not a hosted agent, not a code review service, and not a way to run an AI tool on a server you do not own. The AI process keeps running on your machine, under your credentials, in your project directory.

That framing matters because it sets the trust question. The README describes the relay server as "zero-knowledge": the server never sees your unencrypted data. Whether that claim holds is something you can partly check yourself, because the repository ships a CRYPTO_SPEC.md file alongside the README, and the CLI exposes a fingerprint you can compare against the mobile client.

How the mirroring works: PTY, WebSocket, and a key exchange

The mechanism is a pseudo-terminal wrapped in an encrypted socket. Termly CLI does not reimplement any AI assistant. It spawns the target tool inside a PTY and forwards the byte stream. Two dependencies make this concrete in package.json: node-pty is aliased to npm:@lydell/node-pty, which supplies prebuilt binaries, and ws provides the WebSocket client. The README states the CLI uses @lydell/node-pty with prebuilt binaries for all platforms, which is why no compiler toolchain is needed at install time.

On top of that transport sits the encryption layer. The README lists "AES-256-GCM + DH-2048 key exchange with fingerprint verification" under end-to-end encryption. The practical consequence is that the relay at wss://api.termly.dev forwards ciphertext, and the mobile client derives the same session key through a Diffie-Hellman exchange. Fingerprint verification is the part you actually use: termly list shows encryption fingerprints so you can confirm the phone is talking to the session you think it is.

Session lifecycle is handled client-side. The feature list mentions "Session Resume - Automatic reconnection with state synchronization", and the v1.9.3 release note says the CLI handles a pairing_expired error from the server on reconnect. That is a real design constraint, not a detail: pairing between a terminal session and a mobile device is time-bounded, and an expired pairing has to be re-established rather than silently resumed. Each session also gets its own WebSocket connection, so sessions do not share a channel.

Auto-detection is the other half of the mechanism. Rather than requiring you to declare a tool, the CLI scans for installed assistants and picks one. The --no-auto-detect flag exists precisely because that heuristic can guess wrong when several tools are on the same machine.

Installing Termly CLI and starting a first session

The README gives a single install path for end users: a global npm install. Node.js 18 or newer is the only stated system requirement, and the package.json engines field agrees with that floor. The README says installation typically completes in 10-30 seconds because there is no compilation step.

npm install -g @termly-dev/cli

After that, the termly command is available globally. Move into the project you want the assistant to work in, then start a session. The README's quick start is two lines:

cd /path/to/your/project
termly start

With no flags, the CLI auto-detects an installed AI tool and launches it inside a PTY, then prints pairing information for the mobile client. If detection picks the wrong tool, name it explicitly. The README shows the tool name as a string, including multi-word names:

termly start /path/to/project --ai "claude code"

Arguments destined for the underlying assistant go through --ai-args. This example from the README resumes a prior Claude Code conversation rather than starting fresh:

termly start --ai claude-code --ai-args "--continue"

Before pairing a phone, check what is actually installed and what the session reports. These three commands are the ones worth running first:

termly tools detect
termly status
termly list

The README describes termly list as a quick list of active sessions with encryption fingerprints for verification. Compare that fingerprint against what the mobile client shows. If they differ, stop the session. For a first run, termly start --debug writes debug logging and is the flag to reach for when the session fails to pair. Beta testers use a separate package, @termly-dev/cli-dev, which installs the termly-dev command and connects to wss://dev-api.termly.dev instead of production.

Where Termly CLI is the wrong tool

The clearest boundary is interactivity. The README says the CLI works with any terminal-based AI tool "that supports interactive TTY mode". That qualifier excludes a large share of real usage. A piped invocation, a scripted agent run, or a tool invoked from CI has no TTY to attach to, and mirroring it to a phone makes no sense. If your assistant is driven by a Makefile or a GitHub Action, Termly CLI has nothing to offer.

Server endpoints are the second boundary, and it is a hard one. The README states that server URLs are hardcoded per environment and cannot be changed by users. There is a local mode, but it is explicitly "Developers only": you clone the repository and run it from source with TERMLY_ENV=local against ws://localhost:3000. So an organisation that wants the convenience of the published npm package pointed at an internal relay cannot do that. The choice is the hosted production relay, the hosted development relay, or running from source.

The third limitation is dependency on a hosted service at all. The encryption design is documented as end-to-end, but pairing still depends on the Termly server issuing and validating pairings, and the v1.9.3 note about pairing_expired on reconnect shows that dependency is visible in normal operation. A session that cannot reach the relay cannot be mirrored.

Finally, the test situation deserves a direct statement. The package.json test script is `echo "Error: no test specified" && exit 1`. For a tool that sits between your terminal and a remote device, that is worth knowing before you point it at a repository containing credentials.

Termly CLI versus running a terminal multiplexer you already have

The obvious alternative is tmux or GNU Screen plus SSH from the phone. The difference in approach is fundamental. A multiplexer keeps the session alive on the host and gives you a raw terminal over SSH; your phone becomes a terminal emulator, and you are responsible for the network path (a VPN, a bastion host, a forwarded port). Nothing is relayed through a third-party service, and nothing is encrypted by the multiplexer itself beyond what SSH provides.

Termly CLI inverts that. It does not try to give you a general-purpose shell. It wraps one specific class of process, the interactive AI assistant, and ships a purpose-built mobile client that speaks an encrypted protocol to a relay. You get auto-detection of installed tools, per-session fingerprints, push notifications, and a pairing flow instead of a password prompt. You give up the ability to attach to arbitrary processes and the ability to choose your own relay endpoint.

For a developer with a stable VPN and a preference for owning the whole path, tmux over SSH is the stronger option, and Termly CLI adds a hosted hop for convenience you may not need. For a developer who wants to approve an Aider edit from a phone without configuring WireGuard first, the trade is the other way. The README's claim that the server is zero-knowledge is what makes that trade defensible, and CRYPTO_SPEC.md in the repository is the document to read before accepting it.

Maintenance status, licence, and what upgrading costs

The repository is not archived, and the last push was on 2026-07-25. The most recent release listed is v1.9.5 from 2026-04-14, whose notes cover Qwen Code support and eight patched Dependabot alerts across axios, lodash, ajv and follow-redirects. Two of those packages, lodash and ajv, are pinned through the overrides block in package.json, so version drift there is managed centrally rather than by the CLI's own code. That is a reasonable arrangement, but it also means the security posture of the published package depends on the maintainers applying overrides rather than on upstream releases.

The licence is MIT, and package.json states it in the standard field. MIT is permissive: it allows commercial and closed-source use, modification and redistribution, with the copyright notice and permission notice retained. It does not grant trademark rights, and it provides no warranty. The project also lists a Ko-fi funding URL, which is a donation channel rather than a commercial support contract. If your organisation needs a support agreement or an indemnity, MIT alone does not supply one, and the repository does not describe any commercial tier. None of this is legal advice; check your own policy.

Upgrade cost is low by design. The CLI ships an auto-update check, described in the README as ensuring you are running a supported version, and the version is semver-tracked with dependencies on semver itself. Because the relay endpoint is hardcoded per environment, a client that falls too far behind risks protocol drift with the server, which is presumably why the check exists. The practical upgrade path is re-running the npm install command and restarting sessions; the README does not document an in-place upgrade command or a rollback procedure, so treat a version bump as a restart of any live mirrored sessions.

Editorial conclusion

Adopt Termly CLI if you already run an interactive TTY-based assistant such as Claude Code, Aider or OpenCode and want to answer prompts from a phone without leaving a laptop session open. Do not adopt it if your workflow is non-interactive (piped prompts, CI jobs, scripted agents) or if you need to point the client at your own relay, since the README states server URLs are hardcoded per environment. Verify first that your tool appears in termly tools detect, that your Node version is 18 or newer, and that the encryption fingerprint shown by termly list matches the one your mobile client displays before you type anything sensitive.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. termly-dev/termly-cli on GitHub