Count a Bot repeating itself, and hand the count to the boundary

[jerelvelarde]

The problem

A model that cannot get something to work retries. It clicks the same button, reloads the same page, writes the same file, and nothing in OpenBot counted it. Every attempt is a real action on somebody's live website and a real charge against somebody's model credit, and the trail recorded thirty of them one row at a time, with nothing to say they were the same row thirty times over.

The boundary could not help. Every rule it can express is about the shape of an action, and the thirtieth click has the same shape as the first: a rule able to refuse the thirtieth would refuse the first, and refusing the first is refusing the product. Only the count separates them, and nobody was counting.

The approach

Every governed action already passes through one function in server/src/computer/gateway.ts, which already writes a row for it, so counting there is nearly free. server/src/computer/repeat.ts keys a call on the tool plus the argument saying which thing it acted on — the ref, the key pressed, the file path, the address being opened — and counts identical keys per Bot inside a sliding three-minute window. A bare tool name is deliberately not a key: a Bot working down a form would otherwise look exactly like one stuck on its first field. COMPUTER_REPEAT_WINDOW_MS widens the window for a slower provider, and refuses to start on a malformed value, because a rule that never fires looks exactly like a Bot behaving itself.

The detector observes and does not block. Blocking here would be a second boundary with rules of its own, invisible on the Boundaries page, unanswerable to dry-run, and impossible to relax for the one Bot whose job really is to poll something. Instead the count goes into PolicyContext as repeat.count, taken before the policy is asked so that a rule decides the very attempt that crosses the line rather than the one after it, and a deployment writes repeat.count >= 10 in the deny list it already has. The field is required rather than optional: an absent identifier throws inside CEL and a throwing deny rule denies, so an optional repeat would make one rule about repetition refuse everything.

Crossing 3, 10 or 25 writes one computer.action_repeated row each, carrying the tool, the count and a readable fingerprint (computer_click ref=e9). Each threshold fires once per run, and a run ends only when the window empties completely. The row is not filed as a refusal, and the audit page gives it its own filter and its own words, because a trail that dresses an observation up as a refusal teaches a reader to skim past the real ones. Its insert failure is swallowed and logged: an observation may not cost an action over a moment's trouble at the audit store, and the decision row still goes to the same store, so a store that is genuinely down stops the action there.

What the detector remembers is capped at both levels, because the id it counts against is the one in the request path, checked against a session and nothing else. Nothing still inside the window is evicted to make room, though: least recently seen is exactly the key a Bot going round a long loop is about to make next, and dropping it would report every call in a tight circle as a first attempt. The count is wrong in both directions, as below, and the Boundaries preset, .env.example and docs/architecture.md say so where an operator meets them and suggest dry-run first.

What is not covered

• It over-fires in one way, and that one costs somebody their Bot rather than their evidence: two calls are the same call when the thing acted on is the same, whatever was typed into it, so ten searches typed into one box are ten repeats and repeat.count >= 10 refuses the tenth. Typed text is left out of the key because it is a password as often as anything else.
• MCP tool calls are not counted. server/src/plugins/store.ts supplies repeat: { count: 1 } so a rule reads false there rather than unevaluable; counting them means a second detector at a second call site.
• The count is in memory and per process, so a restart forgets it and two API replicas split every count: a rule about ten attempts fires at twenty or never.
• It undercounts three ways: a Bot slow enough to spread its attempts wider than the window, one that varies a single argument each round, and one looping around a reload, since a ref only means anything against the snapshot it came from.
• A Bot already holding sixty-four distinct calls inside the window reports one for anything new until one ages out, and reads and scrolls are never counted at all.
• Nothing aggregates this into a view, and there is no rate limiting or back-off.

Merge notes

PolicyContext in server/src/computer/policy.ts gains one required field, repeat: { count: number }, placed after actor rather than appended so a branch adding optional fields at the end stays clear of it. Required means every construction site must supply it — two today, the gateway and server/src/plugins/store.ts — and a third added elsewhere fails typecheck until it does. feat/policy-ask-a-person and feat/routines-and-webhook-triggers both change policy.ts and the gateway, so that is the contract to reconcile first. The rest is list-append: an auditEventTypes entry, an audit filter, a Boundaries preset, and additive blocks in server/src/config.ts, .env.example and docs/architecture.md. No schema change, so no migration.

Verification

• bun run format and bun run format:check — Checked 293 files. No fixes applied.
• bun run lint — exit 0, with 24 pre-existing warnings in files this branch does not touch.
• bun run typecheck — app, server and worker all exit 0.
• bun run test — 628 pass, 5 skip, 0 fail across 70 files. Main's baseline is 594, so this branch adds 34 and takes none away.
• bun run build — app, server and worker all exit 0.

server/tests/computer-repeat.test.ts is the one new file, holding the detector down on an injected clock: counts rising and staying apart, the window sliding rather than tumbling, each threshold once, a dip that does not end a run, both caps holding, and a loop wider than the cap still being counted. The existing gateway, policy and config suites gain the count reaching the policy, the repeat row landing ahead of the decision it explains, a lost observation row not refusing an allowed action, the CEL rule itself, and the malformed windows that stop the server.

By hand, this branch's frontend was proxied to a running API on a spare port, confirming that the Boundaries preset renders with its cost line and that the "Going in circles" audit filter queries cleanly. Nothing was written to that deployment's database or policy, and the branch has not been driven end to end against a Bot, so the server-side behaviour rests on unit tests.

[davidmckayv]

Reviewed against the code and run locally. Full suite passes on a clean database (bun run test:ci), format, lint and typecheck clean.

No security concerns: this touches no auth boundary and nothing it adds can be reached without going through the gateway.