Start with six commands
cortex debug config is the one people forget. It shows the configuration in effect after your profile, your project file and any -c overrides have been merged, which is usually where a surprising behaviour comes from. cortex debug config --diff narrows it to where your project file and your profile disagree, and cortex debug config --env adds the Cortex environment variables that are influencing the result.
-v and --trace raise console verbosity for a single run, and that output can include the contents of your prompts and files. --debug is the safer switch: it records bounded, content-free diagnostics under the Cortex home diagnostics/ directory, or the directory named by CORTEX_DIAGNOSTICS_DIR. Each entry carries eight fields and nothing else: schema, timestamp, version, operation, trace_id, span_id, status and duration_ms. There is no prompt text, no file content, no path and no account identifier, because the recording API takes no user-supplied string at all. A journal file stops at 2 MiB, the directory keeps at most 64 of them, entries older than 7 days are pruned, and on Unix-like systems the files are written owner-read-write only. It never overwrites ./debug.txt, and it never uploads anything.The service, the host, and signing in
The coding service is temporarily unavailable
This means the CLI could not reach the coding service. The message is deliberately the whole story: the CLI does not name a provider, an SDK or a transport, so there is nothing further hidden behind it. Four checks, in order:- Can you reach
api.cortex.foundationfrom this machine? - Is a proxy in the way?
HTTPS_PROXYandHTTP_PROXYare honoured forcortex scrape, but corporate TLS interception can still break other calls. - Is
CORTEX_API_URLset to something unexpected?cortex debug config --envwill tell you. - Are you signed in? Run
cortex whoami.
This PC and SSH Code execution require an already connected Code session
You selected This PC or SSH, withCORTEX_COMPUTER or CORTEX_SSH_HOST, without a connected Cortex Code session. Those hosts are never created on the fly, and Cloud is not quietly substituted, because running your tools somewhere other than where you asked is worse than refusing. Either resume a session that already has a host, or unset CORTEX_COMPUTER to use Cloud. See Cloud, This PC, and SSH.
Sign-in does not complete
Device and single sign-on flows, expired credentials, and headless machines with no browser are covered on Sign in.cortex login status reports where you stand, and cortex whoami shows the account a run will use.
The interface will not start
The CLI needs a terminal on both standard input and standard output. In a pipeline, a CI job, or under a wrapper that redirects either one, it refuses to start and points you atcortex run or cortex exec. That is the fix, not a workaround: see Headless and scripting and CI and automation.
The agent will not change anything
Work down this list in order. One of the six is almost always the answer, andcortex debug config --diff shows what differs from the defaults.
1
Check the mode
Plan mode is read-only by design. Press
Shift+Tab to cycle to Agent. See Plan and Spec modes.2
Check the sandbox
--sandbox read-only blocks all writes. workspace-write confines them to the workspace instead of forbidding them.3
Check the approval policy
With
--ask-for-approval never and no autonomy granted, the agent may be silently declining rather than prompting you.4
Check the permission table
The
[permission] table in config.toml can deny editing, or specific shell command patterns, outright. A project file can carry it too, and a project file beats your own. See Permission policy.5
Check the agent
An agent defined with read-only tools cannot write, whatever the session policy says.
cortex agent show <name> prints its definition.6
Check for Spec mode
In Spec mode the mutating tools stay locked until the submitted plan is accepted.
A tool is not available
[permission] table. --enabled-tools and --disabled-tools are not the cause, because cortex exec accepts them only alongside --list-tools. Tools the agent uses lists the full set and what each one needs.
An MCP server is not connecting
- The local command is not on
PATHin the environment the CLI launches it from. - A
--was missing fromcortex mcp add, so the server’s own flags were parsed as CLI flags. - The URL points at localhost or a private range and needs
--allow-local. - The bearer token environment variable named in the configuration is not set in the environment the CLI is running in.
Runs, limits and output
A run times out
cortex exec defaults to a 600-second timeout and 100 turns. Raise both for a genuinely large task:
--command-timeout or execution.command_timeout_seconds instead. Breaking a large task into several smaller runs is usually better than raising the ceiling: each run starts with a clean context and you get to check the work in between.
Quota exhausted
When the quota for your plan runs out, the run stops and the composer is held:Add a follow-up — held until quota resets. Follow-ups you type queue until the window resets rather than being lost. /usage shows the detail. See Plans and quotas.
Output is truncated or mangled
- Use
--color neverfor logs and pipelines, or setNO_COLORin the environment. - Use
-o jsonor-o stream-jsonwhen something downstream parses the output. The shape oftextoutput is not a contract, and it can change between releases; the JSON envelope is the stable surface.
Disk usage keeps growing
A build from source fails
On Linux, the optional audio and desktop components need ALSA headers, so install them and use the toolchain the repository pins:Report a problem
--include-logs attaches recent local log output to the report, so read it first if the run involved anything you would not want to share. Submissions queue in the Cortex home feedback/ directory when you are offline and go out on the next successful call. cortex feedback history shows what you have sent.