[bug] A scheduled browser run can be saved on 25 of 26 agents that cannot perform one — and on cloud-only agents it skips forever telling you to run `pags up`

[serge-ivo]

The offer

run_browse requires the agent to declare workflow: "BROWSER_TASK" — startBrowserTask checks it
explicitly (routes/instances-browse.ts:51). Across the 26 instances on this account:

workflow	instances
null	17
CODING_SESSION	7
JOB_APPLY	1
BROWSER_TASK	1

The console offers "Run browser task" on all 26. ACTION_LABELS (TriggersSection.tsx:97-103)
hardcodes the seven actions with no gating, and lib/triggers.ts:44 accepts any of them for any
instance. A cron trigger that can never do anything saves cleanly and looks healthy in the list.

The ordering bug that makes it permanent

startBrowserTask runs its two preconditions in the wrong order:

await requireLiveRuntime(env, instanceId, userId);            // :45 — HttpError(503), transient
…
if (caps.workflow !== "BROWSER_TASK")
    throw new BrowseError("this agent is not a browser-task agent", 400);   // :51 — permanent, free

The permanent, deterministic, zero-cost check runs after the transient, environmental one.
That matters because lib/triggers.ts:346 classifies the two outcomes differently, and correctly:

if (status !== 503 && status !== 409) throw e;   // 400 → real failure
// 503/409 → skipped, failure_count stays 0, retry next schedule

So an agent with a runner that simply isn't a browser agent gets the honest 400 and the trigger fails
loudly. An agent with no runner at all never reaches the capability check. For the 17 cloud-only
instances the 503 fires first and the trigger is recorded as a skip — failure_count stays 0, so it
never surfaces as unhealthy — and the user is notified, every single fire, forever
(lib/triggers.ts:354):

⏭️ Scheduled run skipped — your runner is offline — run pags up. It'll try again next schedule.

The same agent's Settings tab says (SettingsTab.tsx:806):

This agent runs entirely in the cloud — no local runner (pags up) needed.

Two surfaces giving contradictory advice about one agent, and the wrong one is the one on a schedule.
pags up cannot help: up.ts skips instances whose capabilities.runtime is null, so following the
instruction produces "None of your agents need a local runner" and the trigger keeps skipping.

Fix

Swap the two checks in startBrowserTask. Ask the free permanent question before the expensive
environmental one. A non-browser agent then fails with a reason that is true and actionable, and the
trigger's failure count reflects reality. This alone converts an infinite polite lie into one honest
error.

Then gate creation, server-side. run_browse should be rejected at createTrigger for an
instance whose capabilities don't declare BROWSER_TASK — the same wiring-time posture as the
supervision rules (#183) and the connection filters (#182): reject while the human is present, rather
than at 3am on a schedule.

The gate must not live in the console. There are three equal surfaces onto this — the console, the
API, and the MCP tool create_instance_trigger — so a TriggersSection fix would leave two doors
open. Console-side, the action picker should then derive its options from the instance's resolved
capabilities (already attached to every entry of /v1/instances/my/instances), so the picker and
the validator cannot disagree.

Relationship to #353

Same component, different axis. #353 gates the sync_connector connector picker on deployment
configuration; this gates the action picker on agent capability. Both are TriggersSection
offering work that cannot happen, and whoever picks up either should do both — the shared conclusion
is that this picker's whole vocabulary is hardcoded and gated on nothing.

Class: #351, #353, #354 — a surface reporting a capability the runtime will refuse.

[serge-ivo]

Correction: two doors, not three — the fix is cheaper than the body says

The body says the console, the API and the MCP tool create_instance_trigger are "three equal surfaces", implying three places to gate. Checked it: MCP is a thin proxy, not a parallel implementation. workers/mcp/src/instance-tools/triggers.ts:74 builds the call and hands it to authedCall("/v1/triggers", …) — it does not touch lib/triggers.ts or D1 itself.

So the real shape is: one server-side gate in trigger validation covers both the API and MCP, and the console picker only needs to stop offering what the validator will now reject. The conclusion in the body is unchanged — the gate must not live in TriggersSection — but the work is one validator plus one picker, not three gates.

Same is true of create_supervision for #354, checked at the same time: it proxies to POST /v1/instances/:id/supervision, so that route's fix covers MCP for free.

Worth stating as a general property of this codebase rather than a fact about two tools: the MCP worker proxies the REST API. Any capability gate belongs at the route or lib layer, and gating there is automatically complete across all three surfaces. Gating in a console component is automatically incomplete.

[serge-ivo]

Fixed on main — 863ee94 (API), 93fab01 (console + MCP description), c854ea0 (e2e).

The ordering bug is gone. startBrowserTask now asks the free, permanent, deterministic
question first and requireLiveRuntime second. A run_browse trigger on an agent that is not a
browser agent gets the honest 400 and increments failure_count, instead of 503-ing into a skip
that leaves the row looking healthy forever.

The offer is derived, not a second list. lib/trigger-capability.ts (pure, tested) maps an
action to the capability its executor demands — run_browse → capabilities.workflow = "BROWSER_TASK", read from the same registry startBrowserTask reads — and produces the refusal
sentence. One entry per action that has a requirement; the other six need nothing declared,
because dispatching into the instance's own DO is what being an instance means.

• Server gate: POST /v1/triggers and an action-changing PUT refuse with that sentence.
  Per your correction, this is the one gate: MCP create_instance_trigger proxies to this route,
  so it is covered without a second check. POST /v1/triggers/preview also takes instanceId
  now, so the problem is reported while you are still looking at the picker.
• Console: ACTION_LABELS is deleted. The picker renders from
  GET /v1/triggers/actions?instanceId=, so it holds no vocabulary of its own and cannot
  disagree with the validator in either direction. An unavailable action is shown disabled
  with the reason, not hidden — "why can't I schedule a browser run here?" needs an answer, and a
  missing row is not one.

Already-saved impossible triggers: surfaced, not touched. Every listed trigger carries
unavailable, and the row says "This trigger can never run" plus the reason instead of showing a
healthy next-run time. They are not deleted or disabled — that is the user's call, and Delete is
right there — and an update that renames or disables one still works, so tidying up does not
require deletion. They now also fail loudly rather than skipping, so failure_count is finally
true.

The pags up message: derived from what the agent declares, reusing
classifySubordinateConnectivity's existing vocabulary. A cloud-only agent is told "Runs in the
cloud — it needs no runner and is always reachable. A browser run needs one, so this schedule
cannot run here — check the agent's declared capabilities (runtime + workflow), or delete the
trigger." No pags up, because up.ts skips instances whose runtime is null and the Settings
tab already says so. An agent that genuinely needs a runner keeps the old wording. Unknown
capabilities fall back to the runner wording, and a capabilities read that comes back empty
ALLOWS — the same asymmetry #354 documents: ownership is already proven, so a null is a failed
read, not evidence.

Tests: lib/trigger-capability.test.ts (14), a skip-notification case in lib/triggers.test.ts,
and an e2e that pins both console halves (disabled option with reason; impossible saved row
marked). CI green on c854ea0.

Not done here — #353 stays open. The sync_connector connector picker gates on deployment
configuration rather than agent capability; it is the other axis on the same component and it
lives in the Drive/WorkDrive lane someone else is holding.