A CLI harness is a local binary porto already knows how to spawn. Auth stays in that CLI’s own login. Settings does not take a key for these (except Mistral Vibe, which reuses the Mistral API key).
Run the porto backend as the same OS user that logged into the CLI. A launchd service or Docker API will not see ~/.claude / Codex / Grok auth.

​
Seat-ready harnesses

Best default if you already use Grok Build / Grok CLI.
1

Install and log in

2

Confirm the binary is on PATH

3

Add a seat

Settings → Providers shows Grok on the CLI rail. In the room, Add agent → Grok. Default model is grok-4.6. grok-4.5 is selectable.

​
On the rail but not seats yet

​
If a CLI seat will not start

The backend resolves an absolute path. A GUI-started process often has a thin PATH. Start the API from a terminal where which grok (or claude / codex) works, or put the binary in a directory that is always on PATH.
You logged in as user A and the API runs as user B. Re-login as the API user, or set PORTO_CLI_AUTH_ROOT / PORTO_CODEX_AUTH_HOME if you keep auth outside $HOME.
Grok on the CLI rail is the local grok binary. Grok — xAI API is a cloud key (xai-…). They are different providers. Pick one on purpose.