One manifest, two halves, a signed archive
How it works
From one manifest to two halves
A plugin declares an agent half, a GCS half, or both in a single manifest. The platform installs each half into its own sandbox and wires them together.
Agent half
Python plugins on the companion computer
The agent half runs as a Python subprocess in its own sandbox. It requests capabilities up front, and the host only grants what the operator approves. Plugins read telemetry, drive hardware, and add on-vehicle behavior without touching the core.
- ✓Subprocess-per-plugin isolation
- ✓Explicit, per-capability permissions
- ✓Hardware, sensor, and behavior plugins
GCS half
Sandboxed panels in Mission Control
The GCS half loads in a sandboxed iframe and mounts into a named UI slot. It talks to the host over a message channel with capability tokens, so a panel can only reach what it was granted. Custom tabs, overlays, and controls slot in with no host fork.
- ✓Sandboxed iframe, no host access by default
- ✓Capability tokens per message
- ✓Named UI slots for tabs and overlays
Trust
Signed, sandboxed, permissioned
An extension is a signed archive. Both halves run sandboxed, and every capability is granted explicitly at install.
- Archive
- .adosplug, signed
- Agent sandbox
- Subprocess + capabilities
- GCS sandbox
- iframe + tokens
- Permissions
- Explicit, per-capability
- SDKs
- Python + TypeScript
name: battery-health
version: 0.1.0
agent:
entrypoint: plugin.py
permissions: [telemetry.read]
gcs:
slot: node.detail.tab
permissions: [ui.tab]Build an extension
Both halves ship from one manifest and one signed archive. Browse the open-source registry to see it in action.
Browse the registry