Install a coding CLI

Why these are separate installs

Termdeck drives the official CLI, unmodified, under your own subscription. That is what keeps your local repository, environment variables, credentials, MCP servers, and model access working exactly as they do in a terminal. It also means Termdeck never sees your provider password: each CLI stores its own credentials in its own config directory, and Termdeck reads the state rather than the secret.

Claude Code

npm install -g @anthropic-ai/claude-code
claude

Running claude once starts the login flow. Sign in with the Anthropic account whose plan you want the turns billed against.

• Sessions on disk: ~/.claude/projects/<project slug>/<session id>.jsonl
• Resume in a terminal: claude --resume
• Config directory: ~/.claude, or wherever CLAUDE_CONFIG_DIR points

Claude is the engine with the deepest Termdeck integration: live permission prompts, sub agent status, checkpoint restore and MCP server state all come from Claude's own stream. Slash commands come from two places. The CLI names them, and Termdeck reads their descriptions and argument hints off disk, including any your project defines.

OpenAI Codex

npm install -g @openai/codex
codex login

• Sessions on disk: rollout files under $CODEX_HOME/sessions
• Resume in a terminal: codex resume
• Config directory: $CODEX_HOME, defaulting to ~/.codex

Codex has native plan mode, and Termdeck exposes it in the same picker as the other engines. The slash palette lists the skills installed for a Codex chat with their descriptions, but Codex has no slash commands of its own. Picking one writes it into the composer as text for the model to act on, rather than running a command.

xAI Grok

npm install -g @vibe-kit/grok-cli
grok login

• Sessions on disk: Grok's own session files, shared with the terminal
• Protocol: Agent Client Protocol, driven through grok agent stdio

Use grok login so turns run against your SuperGrok subscription. Grok has no plan mode of its own, so Termdeck's Plan option behaves as read only there and the interface says so under the picker.

How Termdeck finds a CLI

The agent asks the operating system the same question your shell asks: where on Windows, command -v on macOS and Linux. Anything on the path counts as installed, which matches what happens when you type the command yourself.

A machine that has just had a CLI installed is picked up without restarting anything: a negative answer is only cached briefly before being rechecked.

If a binary lives somewhere unusual, name it explicitly in the agent's environment:

Add them to ~/.termdeck/agent.env and restart the agent. Note that a background service does not inherit your login shell's environment, so a CLI that only works after your shell profile runs is exactly the case these variables exist for.

Confirming a CLI is signed in

Open Settings, then Machines and accounts. Each machine card lists the three engines with one of four states:

The distinction in the last row matters more than it looks. "We could not tell" and "it is fine" are the two answers a diagnostic must never confuse, so Termdeck reports the uncertainty rather than guessing in either direction.

Where the engines differ

Termdeck uses one vocabulary across all three so switching engine mid project does not rename every control under you. The mapping is honest about the places where an engine behaves differently, and the interface prints the caveat under the picker.

Permission mode names and their per engine behaviour are covered in full on Approvals and permissions.

Running more than one at once

Nothing stops you from having a Claude chat, a Codex chat, and a Grok chat running at the same time, on the same machine or on different ones. They are separate processes with separate transcripts. A common split is a premium subscription on the hard problems and a cheaper engine on the routine work, with the usage dashboard showing whether the split is paying off.