--- title: Letting an agent run its checks here (cloud-enforce window) --- # Letting an agent run its checks here (cloud-enforce window) ## What it is An approval card you may see in the Inbox when an agent is blocked. When this machine's testing setting is **cloud first** ([Where checks run](where-checks-run.md)), heavy checks — the test suite, type checking, lint, the build — run on remote test machines rather than here, so the machine stays responsive while many agents work. When that arrangement is stopping an agent from getting anything done, the agent can now **ask** you for a short window in which its own checks run here instead. You decide. **The card is an ordinary approval.** It appears in the Inbox and the Approvals hub like every other one, with the same Approve and Reject, and the same record afterwards. The agent tells you why it is asking, in its own words. **It exists only under cloud first.** Under **cloud only** no window opens a local lane — heavy work never runs here — and under **this computer** checks already run here, so there is nothing to ask for. ## Where to find it The card arrives in your **Inbox** and in the **Approvals** hub, exactly like any other approval. There is no settings page for it — you only ever meet it as a card, and only when an agent has asked for one. ## How it behaves ### What you choose The card offers a single choice, combining **who** the window covers with **how long** it lasts: - **This agent only** — the agent that asked. This is the default, and it is listed first. - **Every agent on this machine** — a deliberate widening, for when the whole fleet is stuck rather than one session. Each can be paired with a length — a quarter of an hour, half an hour, or two hours, plus the length the agent actually asked for, which is what the card starts on. **Approving without touching the picker gives the agent exactly the length its request asked for**, so what the card says and what gets granted are the same number. Beside the **Approve** button the card also states the decision in words — "Approve lets every agent on this machine run locally for 30 minutes" — and that sentence changes as you move the picker, so a window that reaches further, or runs longer, than you meant can never be granted by accident. The window closes by itself at the end; there is nothing for you to remember to switch back. ### What a full check run costs here The card also has a **Cost on this PC** line: how long the last full check run on this machine took and the most memory it used, with the date — for example "The last full check run here took 29 min and used up to 17.0 GB of memory (Sep 25)." It is a measurement, never an estimate. When no full run has been measured here yet, the card says exactly that. Only a run that did its heavy work on this machine counts. A full run whose checks were sent to the remote machines only waits here and uses little memory, so it would make a local run look cheap — it is never shown. The measurement comes from the watch that already follows every agent command running ten minutes or more, so a shorter run is not measured. ### What it does, and what it does not - **One agent, by default.** Approving for one agent leaves every other agent on the box exactly as it was. Only the wider option covers the machine. - **It always expires.** There is no lasting version of this. The lasting choice is the testing setting itself — Dev Pipeline → Setup → **Where checks run**, or `npm run testing`. - **Your machine stays protected.** A window never changes the testing setting and never turns enforcement off for anyone else. Nothing an agent can do in its own environment can open one — only your click can. - **You can always see what is live.** Every check that runs under a window says so on its own output, naming the window and when it closes, and `npm run testing` and the Setup card list every window that is currently open. A run happening here is never silent. - **A busy processor does not overrule it for the agent that asked.** Approving keeps that agent's checks on this machine even while the processor (CPU) is busy. They still wait their turn behind other heavy work, so they may run slower. Low memory, crashing processes or programs that are slow to start still stop a check, because then there is no room left to run it. The card says "even while the CPU is busy" so you know this before you click. - **Widening it to every agent keeps that promise for the agent that asked, and no further.** Every other agent keeps the busy-processor protection: when the processor is busy, their checks still go to the remote machines, so the whole fleet cannot pile onto one busy machine at once. ### One thing it does not cover The window covers the normal ways of running checks — the project's own test, type-check, lint and build commands. A hand-typed low-level tool may still be refused, because the outermost layer that intercepts those cannot tell one agent from another. That is a known limit rather than a fault, and the run says so when it happens. ## For agents Ask with `POST /cloud-enforce/approval-request`, sending `{"reason": "…", "minutes": 30}`. The session that gets the window is the one the credential was issued to, taken from your spawn token — you cannot ask on another session's behalf, and the request always asks for the single-agent scope. **The window you get is the length you asked for**, unless the approver deliberately picks a different length or widens it to the whole machine. The card also shows the approver what the last measured full check run on this machine cost, so ask for the length you actually need. You are told either way: approving or declining both come back to you, so there is nothing to poll. See [approvals-hub.md](approvals-hub.md) for where the card appears, and [inbox-alerts.md](inbox-alerts.md) for how the inbox sorts what needs you. ## Related [Where checks run](where-checks-run.md) is the one setting this window briefly lifts for one agent. [The Approvals hub](approvals-hub.md) is where every pending approval is listed, this one included. [Inbox alerts](inbox-alerts.md) explains how the inbox decides what needs you. [The Dev Pipeline](dev-pipeline.md) covers the check-and-land workflow whose heavy steps normally run on a remote machine — the arrangement this window briefly lifts.