Supported coding tools

Task Machine runs agents on coding tools that are already installed on your machines, and it ships an adapter for each tool it supports. An agent does not run on a model directly — it runs through one of these tools, on a computer you control, using the credentials and software already there. This closing chapter of the part names the tools Task Machine knows how to run, explains how a machine comes to offer one, and what to do when a tool you expect is missing.

The supported tools

Task Machine ships runtime adapters for Claude Code, Codex, OpenCode, OpenClaw, Hermes, and Pi. Each is a coding tool you install yourself and run from your own machine; Task Machine detects it and drives it through its adapter, normalizing its command and output so an agent's work reads the same whatever tool ran it. A tool is supported precisely when an adapter exists for it — the list grows as adapters are added, and the runtimes view on any connected machine is the live source of what that machine currently offers.

Which models and reasoning levels an agent can choose are not fixed by Task Machine but reported by the tool itself: the daemon asks each detected tool what it can do and records the answer on the runtime, so an agent profile chooses from what the installed tool actually exposes rather than a hardcoded list.

Claude Code uses whichever credential the machine already has

Each tool runs with the credentials already present on the machine, and Claude Code is the one where that choice is explicit. When an agent runs on Claude Code, the adapter checks how the tool is signed in and picks an auth mode for the run: if the machine has a local Claude subscription login, the run uses that subscription and the adapter deliberately drops any ANTHROPIC_API_KEY from the run's environment so the login is what authenticates; otherwise, if an ANTHROPIC_API_KEY is set, the run uses that API key. A run only proceeds when one of the two is available — if the machine has neither a subscription login nor an API key, the adapter refuses the run rather than starting Claude Code with no way to authenticate. So a Claude Code runtime is detected and shown as soon as the claude executable is on the path, but it can actually run agent work only on a machine that is also signed in one of those two ways.

A tool becomes available by being detected

A tool shows up in your workspace because the daemon found it on the machine, not because you registered it in the app. When the tama daemon checks in, it looks for each supported tool's executable on the machine's path; for every one it finds, it reports the tool with its executable path and version, and that becomes a runtime on the machine. Detection is the whole onboarding step — install the tool so the daemon can find it, and it appears on its next check-in.

Because detection is per machine, the tools available to your agents are the union of what is installed across your connected machines. A tool installed on one machine is offered there and not on a machine that lacks it, which is what lets you keep different machines specialized. Recording the executable path and version alongside each detected tool also lets a workspace owner confirm exactly what will run before enabling it for agents, as the runtime machines chapter describes.

A tool you expect but do not see

If a supported tool is installed on a machine but not showing as a runtime, the usual cause is that the daemon could not find its executable on that machine's path when it last checked in. Confirm the tool runs from a normal shell on that computer, then let the daemon's next heartbeat refresh the machine's report — tama runtimes shows what the daemon currently detects, so you can check from the machine itself before looking in the app. A tool the daemon never detects is simply not offered to agents, since there is nothing for an adapter to run.

Even a detected, working tool is not necessarily in use: a workspace owner can leave a runtime disabled for agents, in which case it stays visible but takes no new agent work. Detection makes a tool available; approval decides whether agents may use it — the boundary that Stay in Control is built around.

From here, you have an agent, a profile that bounds it, a machine to run it, and the tools it runs on. The next part is what agents read and produce as they work — start with memories.