> ## Documentation Index > Fetch the complete documentation index at: https://continuum-three-olive.vercel.app/docs/llms.txt > Use this file to discover all available pages before exploring further. # Troubleshooting > Common problems and how to resolve them — missing or greyed-out quota gauges, provider CLIs Continuum cannot find, and how to verify each one is installed. Continuum drives provider CLIs as child processes. If a provider's quota gauge is missing or greyed out, the most likely causes are: 1. The CLI is not installed. Verify with `which claude`, `which codex`, `which cursor-agent`, `which grok`, `which agy` (Antigravity / Gemini), or `which opencode` in a terminal. 2. The CLI is installed but not logged in. Run it manually (e.g. `claude`, or `opencode auth login`) to complete authentication. 3. The CLI is in a path Continuum cannot find. Continuum resolves binaries rather than hardcoding paths, but only searches common install locations. If the binary lives somewhere unusual, add it to your shell's `PATH`. After installing or authenticating a CLI, go to **Settings → Providers** and check the provider's status dot there. This is correct, not a bug. Some Codex plans have a weekly limit only and no 5-hour session window. On those plans Continuum promotes the weekly figure into the main gauge and labels it **weekly limit**, and does not render a separate weekly card underneath — showing an empty 5-hour meter for a limit that doesn't exist was the older, worse behavior. On a plan that has both, the main gauge shows the 5-hour **session** window and the weekly card appears beneath it. Devices join through email sign-in, not a QR code. If a device isn't connecting: **Step 1: Confirm both devices are signed in to the same account.** On each, open **Settings → Account**. A device that was skipped past sign-in ("Skip for now") is not in the mesh. **Step 2: Check the device mesh is on.** **Settings → Account** carries a **Device mesh** switch. Signing in turns it on, but an earlier explicit "off" is preserved. **Step 3: Read the status on the device row.** **DISCOVERING…** or **OFFLINE · last seen …** means the host hasn't checked in yet. On the phone you'll see *"Waiting for \. Make sure it's awake."* — most often the host machine is asleep, or the app isn't running there. **Step 4: Look for a specific error.** *"Device pending approval; approve it on the Mac. Retrying every 30 seconds."* means go approve it under **Pending approval** on the host. *"Sign in again to manage your devices."* means the session token expired. *"Device limit reached (10). Remove a device to add this one."* means exactly that — an account holds at most 10 devices. **Step 5: Give it 90 seconds.** See the next entry: a stalled enrollment repairs itself. This usually repairs itself. If a host's enrollment stalls or goes stale, a watchdog cancels the hung attempt after about 30 seconds, and the host's 60-second publish cycle re-enrolls it. On a non-transient failure the stale enrollment record is cleared once per launch so the next attempt starts from scratch. **Wait about 90 seconds before intervening.** Transient network and rate-limit errors deliberately do *not* clear the record, so a flaky connection won't cause a re-enroll loop. If it's still stuck after a couple of minutes: quit and relaunch the app on the host, confirm the host machine is awake and online, and check that the account is still signed in there. Remote hosts are registered in **Settings → Devices**. **Add a Linux device** gives you a one-line enroll command; **Advanced** covers Tailscale, SSH, and cloud hosts. * **The button is dimmed.** The inline hint under it explains why — usually a missing SSH username, an unreachable host, or Tailscale not running. Fill in the field and retry. * **Setup runs but the host never goes healthy.** On Linux, Continuum installs the Go `continuum-agent` as a service — check the service status and `~/continuum-agent.log`. On macOS it installs Continuum in headless-agent mode; check its log. You can add the host and connect it later if the reachability probe fails. * **"Couldn't reach `:`."** The agent isn't listening yet. Verify network connectivity to the host and that the agent is running there. * **"Update Continuum on `` to connect …"** The host is on a build too old for the current connect path. Update it. Windows Smart App Control, WDAC, and SmartScreen judge executables by signature and reputation. Public tagged Windows releases are Authenticode-signed — the release pipeline refuses to publish an unsigned one and verifies every executable after packaging. But a **newly signed** binary still has to accumulate SmartScreen reputation, so a "Windows protected your PC" prompt on first launch is expected for a while after a new certificate or a new release. Choose **More info → Run anyway** if you trust the download source. Development or untagged builds are deliberately unsigned and will be blocked outright by Smart App Control. Install a tagged release from the official download page rather than a development artifact. Read the specific message — they mean different things: * **"That model needs Continuum hosted inference. Upgrade to Plus, Max, or Ultra — or connect your own provider key."** You picked a hosted model your plan doesn't include. Either subscribe, or pick a model backed by a provider account you've connected. * **"Weekly hosted-inference budget reached. Add prepaid funds or upgrade your plan."** The weekly budget is spent. Top up the **Usage balance** on the Usage tab, or wait for the window to roll — it resets seven days from your plan start, not on a calendar boundary. See [Hosted Inference & Billing](/docs/features/hosted-inference). * **"You've reached the hosted-inference allocation your organization set for you."** Your admin capped you below your plan and left overage off. Ask them to raise the cap or enable extra usage; there's a budget-request flow for exactly this. * **"\ is not permitted for your team by your organization admin."** The model is blocked by org policy. This is enforced at the gateway, so switching clients won't work around it. * **"Couldn't start the session: …"** or **"The cloud runner couldn't start the session: …"** A genuine host or runner failure; the trailing text is the reason. * **Copy that says the session may still be provisioning.** Starting a session provisions a worktree, runs the repo's setup script, and cold-starts the agent before it answers, so a slow start is not a failure. Continuum says so rather than pushing you into a second spawn — wait, then check whether the session appeared before retrying. This is the multi-account safety net working as designed. When a session is pinned to a specific provider account, Continuum refuses to spawn it under the wrong subscription — it fails closed instead of silently falling back to your default account. A session refuses to start (and surfaces a re-authenticate prompt) when: * The pinned account was removed from **Settings → Providers**. * The account has no stored credential — for example, a login that expired. * The app just started and hasn't finished replaying its saved accounts yet. Retry in a moment. Open **Settings → Providers**, find the account, and re-authenticate it. Default accounts are never affected and spawn exactly as they did before multi-account. This is expected when the iPhone app is built with a personal (free) Apple Developer account. The analytics sync between Mac and iPhone uses iCloud Key-Value storage, which requires a paid Apple Developer Program membership to sign the required entitlement. On personal-team builds the analytics tab shows "Waiting for Mac sync" and stays empty until you upgrade to a paid Developer Program account and rebuild with the iCloud entitlement signed. There is no workaround within the app. This affects self-built apps only — App Store builds are signed with a paid team. Clients check the host daemon's wire-version number. When two ends are running incompatible versions, features that need a newer wire version are hidden and a banner appears instead. Update the host and reopen the client; the banner clears once the host reports a high enough version. Update paths differ by platform: macOS updates through Sparkle from the in-app updater or **Check for Updates…**; Windows and Linux desktop update themselves through `electron-updater`; the CLI updates when you run `continuum update`. The daemon's HTTP listener starts at port `21731` and tries fallback ports through `21741`; the WebSocket listener takes the next free port above whichever one HTTP claimed. If every port in that range is occupied, the daemon fails to start. Find the conflicting process: ```bash theme={"dark"} lsof -i :21731 ``` Quit it, then restart Continuum. Sensitive daemon operations are written as append-only JSONL under `~/.clawdmeter/audit/`, in a directory created owner-only: * `sends.jsonl` — prompt sends * `swaps.jsonl` — model, effort, and mode changes * `autopilot.jsonl` — autopilot toggles * `auto-router.jsonl` — automatic model routing decisions * `mobile-commands.jsonl` — commands received from a remote client * `cowork.jsonl`, `creds.jsonl`, `sidecar-ask.jsonl` Files rotate at 1 MB or 7 days, whichever comes first. Entries record metadata — timestamps, session ids, operation type — and hashed payload fingerprints, never prompt content or model responses. Read them directly; there is no in-app viewer. They are newline-delimited JSON, so `tail -f ~/.clawdmeter/audit/sends.jsonl` works, as does piping a file through `jq`.