---
title: Where checks run (the testing setting)
---

# Where checks run (the testing setting)

## What it is

Agents run a lot of checks — the test suite, type checking and lint. The heavy ones can run on
remote test machines in the cloud, so this computer stays fast while many agents work, or right
here on this computer. **One setting decides which**, for the whole machine, and it has three
values:

- **Cloud first** — heavy checks run in the cloud. If the cloud is **down** (it has not answered
  for a sustained stretch), a few of them run here at a time, so testing keeps going; when the
  cloud answers again, new checks go back to it on their own. A cloud that is merely **busy**
  never sends work here — busy checks wait their turn in the cloud.
- **Cloud only** — heavy checks never run here, even while the cloud is down. They wait for the
  cloud, and each waiting check says that it is waiting and why.
- **This computer** — heavy checks run here, and nothing needs the cloud or a cloud account.

**Small test runs always stay here**, whichever value is chosen: a quick run of a few named test
files is cheaper here than a trip to the cloud.

**You do not have to choose.** With nothing saved, a machine that has cloud access behaves as
cloud first and one without behaves as this computer. There is no file to edit and no
environment variable to set.

## Where to find it

- **In the app** — the **Dev Pipeline** panel, **Setup** tab, the **Where checks run** card. It
  shows the three choices and, under them, the current state in plain words.
- **At a terminal** — `npm run testing` prints the same information. The app and the terminal
  are built from one readout, so they always agree.

## How it behaves

### What the card and `npm run testing` tell you

- **Next heavy check** — where the next heavy check will run, and why.
- **Cloud** — whether the cloud is answering, or declared down and since when.
- **Set by** — whether the value is this computer's default, or who chose it (a person at a
  terminal, this app, an approved agent request, or setup) and when.
- **Approved windows** — any window a person granted one agent to run its checks here (see
  [Letting an agent run its checks here](cloud-enforce-window.md)).
- **Verdict** — the version of the check service that is running, and whether it follows this
  setting.
- **Warnings** — anything that needs your attention, such as an emergency switch in force or an
  old settings file that disagrees with the saved value. A line the readout could not work out
  says "unknown" rather than disappearing.

### Changing it

- **A person** changes it directly: click a value on the card (it saves at once — the click is
  the decision), or run `npm run testing -- cloud-first` (or `cloud-only`, `this-machine`) at a
  terminal. If a save fails, the card snaps back to the saved value and says so.
- **An agent cannot change it.** It can only **ask**, with
  `npm run testing -- <value> --reason "<why>"`. That raises an approval card in your Inbox naming
  the change and the reason; the setting changes only if you approve it, and declining changes
  nothing. A second agent asking for the same value joins the card instead of raising another.
- **Nothing changes it on its own.** No timer, outage or app process switches it back or forth.

### Older switches

Where checks run used to be spread across several switches. They no longer decide anything:

- `npm run cloud:enforce on` and `off` still work — as shortcuts that set cloud first and this
  computer. `cloud:enforce auto` and a timed `off` (for example `off 30m`) are retired: they print
  a pointer to this setting and change nothing.
- The routing profiles, the routing level and the individual cloud routing toggles are
  **outranked** by this setting; the readout lists any that are set, and marks them as outranked.
- Worktrees made before this setting existed still read the old enforce file until they are
  rebased. The setting keeps that file in step, and the readout says so.

## For agents

- **Read** where checks run with `npm run testing` (add `--json` for the raw readout) or
  `GET /testing-mode` on the control server.
- **Ask** for a change with `npm run testing -- <value> --reason "<why>"`, or
  `POST /testing-mode/request` with `{ "mode": "…", "reason": "…" }`. You are told the outcome; there
  is nothing to poll. Never try to change it another way — every direct path refuses an agent.
- **A refused heavy run** (exit 69) means the setting sends heavy checks to the cloud and the cloud
  could not take it. Fix the cloud, use a small named-file test run, or ask — do not re-run it
  locally some other way. [The Dev Pipeline](dev-pipeline.md) covers the gate these checks feed.

## Related

[Letting an agent run its checks here](cloud-enforce-window.md) — the bounded, one-agent window a
person can grant under cloud first. [The Dev Pipeline panel — part 2](dev-pipeline-panel-part-2.md)
describes the rest of the Setup tab. [Verdict](verdict-panel.md) is the check service that places
each check.