Install AI coding tools

A local runtime has two parts: the Multica daemon, and one AI coding tool it can invoke. Install only the tool you intend to use — you do not need all of them.

1. Choose a tool

A tool that is already installed and signed in needs no extra setup. Tools differ in models, MCP, session resumption, and skill support; the details are in AI coding tools comparison.

Multica currently detects these commands:

"Supported" means Multica can invoke that CLI. It does not mean Multica provides the tool's account, subscription, or model quota for you.

2. Sign in on your machine

After installing, launch the tool once in a terminal on its own and complete its sign-in or model provider setup. If the tool cannot complete requests in the terminal, the daemon's invocations fail the same way.

For CodeArts, verify the non-interactive path with codearts run --model provider/model "Reply OK", not only the TUI. The current CodeArts CLI can let a custom provider work in the TUI while run, models, and serve still require CODEARTS_CLI_AK / CODEARTS_CLI_SK. Multica can discover custom models from ~/.codeartsdoer/codearts_cli.json or .jsonc, but agent runs use codearts run and therefore follow its authorization requirements.

For Reasonix, run reasonix setup and configure a default provider and model before starting the daemon.

For QwenPaw, choose the provider and model in QwenPaw's own configuration. Multica cannot override a QwenPaw model at run time.

For MiniMax Code, install a supported Node.js release (>=22.19 <23 or >=24 <27) and run npm install --global @minimax-ai/code@latest. A global npm install places mcode on npm's global binary path; if command -v mcode or Get-Command mcode cannot find it, add that path to PATH. Then run mcode login. MiniMax Code owns the model selection; Multica cannot override it through ACP.

For DeepSeek Harness, install Node.js 20+ and run npm install -g @deepseek-ai/dsh, then give it the Multica runtime profile — the bundle that implements the --stdio protocol Multica drives, and the reason a bare dsh is not usable on its own. Set MULTICA_DSH_PROFILE_BUNDLE to the bundle to install and the daemon adds it for you, or add it yourself with dsh plugin --profile multica add <bundle>. <bundle> is anything dsh plugin accepts — an npm package name, a directory, or a packed tarball — and Multica's own bridge lives at multica-ai/dsh-multica-runtime. It is not on a public npm registry yet (multica#6936), so today a self-hosted team builds it from that repository and points the variable at the build directory, or at the tarball npm pack produces — the latter if the machine running the daemon is not the machine that built it. A package name becomes the simplest option once the bridge is published. Whatever you choose, prefer something your own team publishes or builds: this value is installed into every daemon host's DSH home without further confirmation, so an unvetted third-party package is a supply-chain decision, not a convenience. If you installed DeepSeek Harness Desktop instead of the npm package, the daemon also looks for the CLI shims that app generates, under its own per-user data directory — ~/Library/Application Support/DSH Desktop on macOS, %APPDATA%\DSH Desktop on Windows. On Windows that is roaming application data, not the install directory: the app installs to Program Files or %LOCALAPPDATA%\Programs, but the CLI it drives lives beside its other per-user state. The version segment in those paths is a generated id, so the daemon enumerates them and prefers the newest. Nothing else is needed on PATH — a generated shim runs the Desktop app's own runtime by absolute path. If DSH Desktop is installed somewhere non-default, point MULTICA_DSH_PATH at the shim. The daemon registers DeepSeek Harness only after dsh --profile multica --probe succeeds, and reports the missing profile on /health when it does not. Set DEEPSEEK_API_KEY (or store it in dsh's own settings) before starting the daemon.

Those login credentials are stored locally by the tool itself. Multica never receives login tokens from Claude, Codex, Cursor, or any other CLI.

3. Confirm the daemon can find the command

On macOS, Linux, or WSL, run:

command -v <command>
<command> --version

In Windows PowerShell, run:

Get-Command <command>
<command> --version

Replace <command> with a command from the table, such as claude, codex, or cursor-agent. The first command prints the executable path.

If the terminal finds the tool but Desktop or the background daemon does not, the two are usually using different PATH values. Restart the app, or set an absolute path through the matching MULTICA_<PROVIDER>_PATH environment variable; full configuration is in Environment variables.

4. Re-detect and confirm the runtime is online

Start the daemon with the CLI:

multica daemon start

If the daemon is already running, restart it after installing a new tool:

multica daemon restart

With Multica Desktop, quit and reopen the app.

Then open Multica's Runtimes page. The tool appears under the target computer and shows as online. You can now select this runtime when creating or editing an agent.

No tools detected

Check in order:

1. Run the tool itself in a terminal to confirm installation and sign-in are complete.
2. Check the actual command name and path with command -v or Get-Command.
3. Run multica daemon logs -f and look for version, path, or authentication errors.
4. Restart the daemon so it re-reads the current environment.
5. Return to the Runtimes page and confirm the computer and the tool are online.

If the tool shows as online but runs still fail, open the issue's run record to see the exact error the CLI returned, or continue with Troubleshooting.

Next steps

• Create and configure an agent — select the runtime you just connected.
• Daemon and runtimes — online status, concurrency, and custom runtimes.
• AI coding tools comparison — compare what each tool can do in Multica.