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, or has reported no working test machine at all, 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 — its machines are all running other checks — never sends work here; busy checks wait their turn in the cloud.
• Cloud only — no check runs here, not even a small test run, even while the cloud is down. Checks 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 stay here under Cloud first and This computer: a quick run of a few named test files is cheaper here than a trip to the cloud. Under Cloud only they go to the cloud too — nothing runs on this computer.

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).
• 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 covers the gate these checks feed.

Related

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