Drivers and providers

Use an application driver when a native API exposes richer operations than generic UI automation, or when the integration needs a long-lived connection or application state. Plugins remain useful for narrower one-shot operations.

If your application already owns its model, persistence and transaction boundaries, start with the Native application SDK. It adapts optional cooperation contracts through the existing Driver SDK and Host.

The driver is not the authority

agent → CLI/MCP → broker → policy/audit
      → DriverProvider → sandboxed driver → application

The owner assigns provider identity and pins the executable digest. A strict manifest declares application metadata, resources and requested mounts. Capability names stay in the assigned driver namespace, and the manifest cannot create policy grants.

The versioned handshake

The persistent stdio contract checks identity and protocol, enumerates capabilities with a catalogue digest, probes health, accepts descriptor-pinned requests, and supports explicit shutdown. Protocol v1 is the baseline request/response lifecycle. Protocol v2 additionally transports negotiated child events, progress, artifacts, dynamic capability changes and cooperative cancellation; a provider may advertise only interfaces that its negotiated protocol can carry.

Start with the local authoring tools

semwright driver scaffold myapp ./semwright-myapp --sdk-path /absolute/path/to/semwright/crates/driver-sdk
semwright --json driver validate ./driver.json
semwright --json driver inspect ./driver.json
semwright --json driver conformance ./driver.json

Build the scaffold and set the actual executable path and SHA-256 before validation. These are authoring examples; scaffolding neither installs a driver nor authorizes its operations.

Conformance is necessary, not complete application certification

On Linux the host stages verified bytes in Bubblewrap and Landlock, scrubs the environment, and applies bounded resources. Other native hosts have their own implementation and evidence boundaries. Conformance checks the pinned executable and protocol in the applicable host; it does not certify every physical desktop.

A useful driver also needs version-specific application tests, failure cases, reference lifecycle coverage and accurate compatibility notes. For cross-application work, read artifact handoff.

Explore the driver catalogue. KiCad has its own GPL-3.0-or-later integration license; do not infer its license from the Rust core.

Source: Driver SDK contract, source references checked 7 October 2026.