CLI: Config & troubleshooting

Last updated September 22, 2026

Signing in and out, picking a default model, and diagnosing the failures that actually happen — plus the fixes.

Sign in, sign out

tempr auth              # interactive prompt (recommended — keeps the key out of shell history)
tempr auth <LICENSE_KEY>  # or pass it directly (it lands in shell history)
tempr logout             # clear the stored credential on this machine

The CLI uses the same license as the IDE — Standard, Pro, or Teams all work, no separate subscription.

In CI, don't run tempr auth at all: set TEMPR_LICENSE_KEY from your secret store, and a run with no stored session signs in from it. The key never appears on a command line.

Default model

Every run needs a model. Set a default once, override per-run when you want:

tempr models                  # the model ids your license can use
tempr config set-model <id>   # default for every run
tempr config show             # what's set, and where the config file is
tempr -m <id> "prompt"        # one-run override
tempr --model <id>            # same thing, long form

tempr auth offers to pick a default right after you sign in. Inside the REPL, /model <id> switches the model for the session, and /model on its own opens a picker over your catalog.

Troubleshooting

Symptom	Fix
`No model configured` on every run	Pass `-m <id>` or run `tempr config set-model <id>` — no default is set on this machine.
Auth errors on a machine that used to work	Run `tempr doctor` to check connectivity; if the credential is stale, `tempr logout` then `tempr auth`.
Turns fail in a CI container but work locally	Check that `TEMPR_LICENSE_KEY` is actually set in the job — without it the run exits 3 with `Not signed in`, and a bad key prints `TEMPR_LICENSE_KEY was rejected` — and pass `-m` explicitly so the run doesn't depend on local config.
Unexpected tool behavior or empty MCP list	`tempr mcp list` shows what's configured; MCP tools only appear once a server is added with `tempr mcp add` or `tempr mcp browse`, and enabled. `tempr doctor` starts each enabled server and reports any that fail.
Can't tell what the agent did	Re-run with `--verbose` for each tool call's full output and token usage, use `/diff` in the REPL to see what the last turn changed on disk, or read the saved session with `tempr history show <id>`.

tempr doctor

tempr doctor checks that the config directory is writable, that the server is reachable, that you're signed in with an active plan and the session can refresh, that your catalog has models, that your default model is set and in that catalog, and that each enabled MCP server starts (--skip-mcp skips that last one). When something misbehaves, run it first — it distinguishes "can't reach the server" from "not signed in" from "configured fine," which covers most first-line debugging. It exits 1 if any check fails, so a CI job can gate on it.

Note

The agent loop runs server-side, so a flaky local connection does not kill an in-flight turn — but doctor is still the fastest way to confirm the machine can reach Tempr at all.

Previous← CLI command reference NextScripts, pipes & CI →