Skip to content

feat(mastra): add Linux Fleet computer-use provider - #3642

Closed
f-trycua wants to merge 4 commits into
mainfrom
feat/mastra-fleet-provider
Closed

feat(mastra): add Linux Fleet computer-use provider#3642
f-trycua wants to merge 4 commits into
mainfrom
feat/mastra-fleet-provider

Conversation

@f-trycua

@f-trycua f-trycua commented Sep 7, 2026

Copy link
Copy Markdown
Collaborator

Superseded by the upstream Mastra integration: mastra-ai/mastra#23284. Further provider development belongs in that PR; this standalone prototype will not be published.

Adds @trycua/mastra, an unpublished ESM provider that gives a concrete Mastra workspace an isolated Linux desktop from an existing Cua Fleet pool. The provider uses published @trycua/fleet@0.1.1 directly and implements Mastra 1.62.0's computer capability.

Behavior

  • Registers all 11 standard Mastra computer tools, with normalized keys, coordinates, scrolling, PNG screenshots, and serialized actions.
  • Creates one owned claim per provider instance, coalesces startup, bounds HTTP requests, and uses the SDK's refreshable OAuth authentication.
  • Destruction drains active work, releases only the owned claim, and verifies absence. Failed or ambiguous cleanup remains retryable. Caller-managed pools are preserved.
  • Rejects unsupported pause explicitly. Shell/files/processes/viewer/checkpoint/clone capabilities and other operating systems are not advertised.
  • Includes a temporary-pool example with model and scripted modes, guest-local browser fixture, independent submitted-value assertion, recovery record, and cleanup command.
  • Uses an independent npm lockfile and dedicated credential-free CI; no change to existing SDK contracts or release pipelines.

Validation

Final draft head: a7be92776. Provider implementation is unchanged from 937b744ef.

  • All 15 deterministic tests pass: GUI mappings, invalid PNG/CRC, key validation, lifecycle races, retained cleanup, ambiguous claim creation, secret/error handling, automatic tool discovery, and actual offline Agent.generate tool execution.
  • Typecheck, build, formatting, and package-content inspection pass.
  • Packed tarball installed into a separate consumer: ESM import, registration of all 11 computer tools, and destruction without allocation pass.
  • Live Fleet run on 2026-09-08 UTC: real Mastra Agent.generate with a scripted LanguageModelV2 fixture completed five steps against a Linux Chromium kiosk page. The agent used screenshots, clicks, and typing; an independent guest command verified the exact submitted value. Before/after screenshots were visually inspected locally.
  • Live isolation verification on 2026-09-08 UTC held two simultaneous provider instances with the same logical id, confirmed different guest names, and proved that the second guest could not see the first guest's fixture state. Both claims were released; the caller-managed pool remained intact until example cleanup deleted its exclusively reserved namespace. A fresh authenticated account listing then contained zero namespaces.
  • The isolation run used harness 8879a5ddd with its owned pool reconciled from one to two slots during the run. Final commit a7be92776 only makes that two-slot capacity explicit at creation and updates the example description; provider code and verification assertions are unchanged. The final creation-time two-slot variant has not been separately rerun live.
  • Dedicated package CI passes; repository-wide TypeScript check is tracked in the checks section.

Known gaps and delivery stage

This remains a draft. The cloud run proves real Mastra orchestration and desktop I/O with scripted decisions; an autonomous vision-model run is not yet certified. Live coverage of every gesture remains uncertified; screenshots, clicks, typing, and simultaneous session isolation have live evidence. No npm publication or merge is requested by this PR's current delivery stage.

The example provisions two billable Fleet slots (4 CPU / 4 GiB each). One-hour TTLs are fallback deadlines, not cost caps. Unconfirmed namespace reservation requires manual ownership verification; cleanup does not infer ownership from an ambiguous response.

Refs #3640.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant