Computer Use Protocol

The Computer Use Protocol package (@allternit/computer-use-protocol) provides the canonical Zod schemas and TypeScript types that power Allternit browser and computer-use runs. It is the shared wire contract between surfaces such as the web platform, desktop agent, Gizzi Code, browser extension, and API clients, and the providers that actually drive browsers and desktops. Use this package when you are:
  • Building a provider or surface that participates in an Allternit computer-use run.
  • Validating inbound/outbound messages in a gateway, adapter, or MCP server.
  • Serializing runs, observations, actions, approvals, and trajectories to durable storage.
  • Sharing structured run data between the Allternit platform and external tools.

Installation

The package is ESM-only and has one runtime dependency, zod.

Quick start

Schema version

Every top-level schema carries a schemaVersion field that must match COMPUTER_USE_PROTOCOL_VERSION ("1.0"). This lets consumers reject documents from an incompatible protocol revision before processing them.

Surfaces, providers, and capabilities

Surfaces

A surface is an Allternit runtime that can start, observe, or control a run.

Providers

A provider is the concrete driver that executes browser actions.

Capabilities

Capabilities describe what a provider or surface can do.

Sessions and devices

Session spec

A SessionSpec ties a run to an account, conversation, and surface.

Paired devices

Devices pair with an account so the platform knows which surfaces are trusted and where runs can be handed off.
Device trust states: unpaired, pending, trusted, revoked.

Surface presence

Surfaces broadcast presence so the platform can route runs to an online instance.

Runs and execution control

Browser run

A BrowserRun is the top-level record of a task.
Run states: queued, running, approval_pending, paused, recovering, completed, failed, cancelled.

Execution lease

A lease prevents two surfaces from controlling the same run at the same time. The monotonic epoch lets receivers reject stale leases.

Handoff and resume

When a run moves between surfaces, a HandoffRequest carries the last acknowledged sequence so the new surface can resume from the right place.

Observations and artifacts

Browser observation

An observation is a snapshot of the browser state at a point in time.
Observation formats: accessibility, dom, screenshot, hybrid.

Artifacts

Artifacts attach binary or structured evidence to observations, actions, and receipts.
Artifact kinds: screenshot, download, upload, trace, recording, receipt.

Actions, approvals, and receipts

Action intent

An ActionIntent describes a single step the provider should execute.
Action kinds: navigate, click, type, press, scroll, select, hover, wait, tab.open, tab.focus, tab.close, dialog.accept, dialog.dismiss, file.upload, download, extract, screenshot.

Action state

Actions move through a lifecycle: planned, resolved, policy_checked, approval_pending, executing, observed, verified, committed, recovering, failed.

Policy decisions and approvals

Before a risky action runs, the policy layer can allow, deny, or require explicit approval.

Receipts

A Receipt is the durable outcome of an action or run.
Receipt outcomes: committed, denied, failed, cancelled.

Events

BrowserEvent is the ordered, sequenced envelope used for run streaming and audit logs.
Event types: run.started, run.paused, run.resumed, run.completed, run.failed, run.cancelled, action.state_changed, observation.created, approval.required, approval.resolved, artifact.created, receipt.issued, handoff.requested, handoff.completed.

Trajectories, workflows, and skills

Browser trajectory

A trajectory records the full sequence of actions, observations, and receipts for a run.

Workflow spec

A BrowserWorkflowSpec turns a successful trajectory into a reusable, parameterizable workflow.

Skill manifest

A skill manifest publishes a workflow as a reusable Allternit skill.

Implementing a provider

The package exports a BrowserProvider interface that any concrete driver can implement.

Validation and error handling

Every export is a Zod schema, so invalid data throws a ZodError with detailed path information.
You can also use .safeParse() for non-throwing validation:

TypeScript types

All schemas export inferred TypeScript types: