Tenux CLI

Tenux runs an agent on the computer you want to reach. The tenux CLI is that agent — install it, pair it, and your computer appears on your phone.

Install

Install the CLI globally with npm (Node.js 22+; supported on Windows and Linux, with macOS experimental):

npm i -g @tenux/cli

Then pair this machine with your Tenux account — this opens a browser link to authorize and stores a long-lived device credential locally:

tenux login

Once paired, start the agent:

tenux start

tenux start runs the long-lived agent — heartbeat plus tunnel / peer-to-peer bring-up — so the machine stays reachable from your phone. Leave it running. Prefer to install from the web? See the install page.

Command reference

Every tenux command is listed below. Run tenux --help or tenux <command> --help for the same list from the CLI itself.

Authentication

Running the agent

AI provider keys

Tenux chat is provider-agnostic: Anthropic, OpenAI, Z.ai (GLM), DeepSeek, Moonshot (Kimi) and Alibaba (Qwen) are supported. On tenux.dev your key lives on your computer, not on our servers. Set it with tenux ai keys set, and chat uses it for models from that provider; for anything else, chat runs on Tenux credits.

Keys are stored in your local config at file mode 0600 and are never printed back in full. Tenux chat picks the local key matching the requested model’s provider and never substitutes a different provider’s key.

If ANTHROPIC_API_KEY is set in the environment the Tenux agent runs in, Tenux chat treats it as your Anthropic key: Claude models run on it, billed by Anthropic to you, not on Tenux credits.

Configuration

The tenux config command group reads and writes individual settings in your local config. Note the asymmetry: get can read six keys, but only three of them are writable with set — the other three are issued at login and are read-only.

MCP — bring any AI into your workspace

Watching the agent live

Restarting

The AI's own browser

Cross-device — a shell on your other machine

While a request is waiting, the CLI prints an awaiting-approval line and keeps polling. Approve it from the Tenux dashboard under Devices → Access requests, or from any open workspace — a request stays answerable for 15 minutes. Approving asks you to type the target device’s name, and it can only be done from a signed-in browser session: an AI with a shell on either machine cannot approve its own access.

The session shows up as a tab in the target’s workspace. That is deliberate — you can watch it from your phone, type into it, or close the tab to kill it. Type ~. at the start of a line to disconnect from your end, the same escape OpenSSH uses. Revoking the pair from the dashboard drops every live session within seconds.

Voice — on-device speech models

Tenux voice mode runs speech-to-text and text-to-speech entirely on this machine — the models below do the work, and no audio is ever stored on Tenux’s servers. Where the audio travels depends on your connection: on a direct peer-to-peer link it never touches Tenux infrastructure at all, and when your phone has to fall back to the relay, voice travels through it in memory exactly as your terminal keystrokes already do. These two commands manage the local install from the terminal.

Android — the local emulator

Android mode runs a real Android emulator on this computer and shows it in your workspace. These two commands get it installed and tell you what is missing.

Bring any AI into your workspace

Your running Tenux agent exposes its workspace — every terminal tab, the workspace file API, and the localhost preview — as an MCP server. Any MCP-capable AI you run on that machine can use it, not just Tenux Chat.

The server name is tenux, so its tools show up under an mcp__tenux__ prefix (e.g. mcp__tenux__terminal_read). Ask the client to list them for the current set — the surface is owned by the agent, not by this page.

The short version

tenux mcp is the server — a stdio bridge to whatever agent is running on this machine. Any stdio MCP client registers it the same way: point it at the command tenux with the single argument mcp. The snippets below are that one fact, spelled out in each client’s own config format — with the agent running (tenux start) first.

Claude Code

claude mcp add tenux -- tenux mcp

Codex CLI

Add a [mcp_servers.tenux] table to ~/.codex/config.toml:

[mcp_servers.tenux]
command = "tenux"
args = ["mcp"]

Cursor

Add to .cursor/mcp.json (project-local) or your global Cursor MCP config:

{
  "mcpServers": {
    "tenux": {
      "command": "tenux",
      "args": ["mcp"]
    }
  }
}

VS Code (Copilot)

Add to .vscode/mcp.json — VS Code’s top-level key is servers, not mcpServers:

{
  "servers": {
    "tenux": {
      "command": "tenux",
      "args": ["mcp"]
    }
  }
}

Gemini CLI

Add to settings.json (project .gemini/ or user-level):

{
  "mcpServers": {
    "tenux": {
      "command": "tenux",
      "args": ["mcp"]
    }
  }
}

Any other stdio client

The pattern above is universal: any stdio MCP client runs the command tenux mcp — the command is the server, so there is nothing else to configure.

Streamable HTTP clients

A client that speaks Streamable HTTP directly, instead of stdio, can skip the command entirely and point at the endpoint:

tenux mcp --print-url        # → http://127.0.0.1:8765/mcp

That prints the URL only. Those clients must send the workspace Bearer token themselves; tenux mcp never prints it.

Approving a client

The first time a client actually attaches, your Tenux workspace asks:

Until you answer, the client can list the tools but every tool call comes back telling it to ask you to approve. “Always allow” is remembered per client in ~/.tenux/mcp-consent.json; “Allow once” and “Deny” last only for that session. A small chip appears in the workspace while a client is attached.

What you are granting

Registering this MCP gives that AI eyes and hands on every workspace terminal plus the localhost preview and the workspace file API. That is the same trust class as giving it a shell — which, if it is running inside a Tenux terminal, you already did — but it widens the blast radius from its own tab to all of them.

If this machine runs an Android emulator that Tenux manages, the AI also gets its screen and its touch/keyboard input — including any app you are signed in to on it.

What it does not get:

Only terminal_create may open a shell — a read/type/wait against a terminal that doesn’t exist returns an error instead of quietly spawning one.

Claude connector — the off switch

If you connected this computer to the Claude app as a custom connector, these commands turn that access off and on instantly, on this computer. Your own workspace and local MCP clients are not affected.

Handing a secret to your agent

When an agent needs a key only you hold (a bot token, an API key), it sends you a link to a page in your Tenux workspace and a short verification phrase. Open the link, sign in, check the phrase, and paste. The value goes straight to your computer, into ~/.tenux/secrets.local.json or the file the agent named. It is never stored on Tenux servers, emailed, or shown back to you. Each link works once and expires (15 minutes by default, at most an hour).

The file gets owner-only permissions on macOS and Linux; on Windows it inherits your user folder’s permissions.

Questions?

Email [email protected].