Introduction

OXP — the Open eXtension Protocol — is a small, neutral specification for IDE extensions. It lets a developer publish an extension once and install it into any IDE that has an OXP host adapter. VS Code, JetBrains, and Neovim all run conformant OXP hosts today; Cursor, Windsurf, and VSCodium inherit support via the VS Code adapter. More adapters land as the ecosystem fills in.

OXP is to IDE extensions what LSP is to language tooling and what npm is to JavaScript packages: a thin, boring, standards-based layer that ends the N×M integration problem.

Why OXP Exists

Today, building an IDE extension means picking a single editor and locking into its ecosystem. A VS Code extension won't run in JetBrains. A JetBrains plugin won't run in Zed. Each ecosystem has its own manifest format, its own APIs, its own marketplace, and its own review process. If you want to support three editors, you write three extensions.

OXP eliminates this. One manifest. One bundle format. One CLI. Publish once, install everywhere.

What OXP Invents

Just three things. Everything else is composition of existing standards.

1. **oxp.json** — a manifest format (~50 fields) covering identity, version, permissions, contributions, and host compatibility.
2. **@oxprotocol/ui** — a fixed component contract (Box, Stack, Button, Text, VirtualList, CodeBlock). Stay inside it and your extension gets the native render path on hosts that support it. Drop out of it and you fall back to webview rendering.
3. CLI host adapters — one small module per IDE that knows how to install, uninstall, and update via that IDE's own tooling. No directory sniffing, no monkey-patching.

What OXP Does Not Invent

Five standards, one schema, one component library. That's the whole platform.

Three Integration Tiers

OXP defines three tiers for IDE vendors. Each tier unlocks more capability, but Tier 0 works today on every VS Code fork with zero effort from the IDE vendor.

What This Unlocks

• For developers: Write standard TypeScript, React, or Rust/Wasm. Publish once. Install anywhere. AI tools work because the code is conventional.
• For IDE vendors (Cursor, Theia, Gitpod, Coder, Zed, JetBrains): An extension story that isn't legally constrained by Microsoft's marketplace ToS. Adopt L1 in a week, L2 when ready.
• For enterprises: Private OXP registries (OCI-compatible), signed by Sigstore, auditable by default.

Current Status

• V1 spec: Finalized at spec/v1/.
• Runtime v0.1: Shipped. Wasmtime 26 component-model host, JSON-RPC 2.0 over stdio, capability broker for log/storage/fs/net/secrets/commands/ui.
• Host adapters: VS Code, JetBrains, and Neovim all run the same .oxp bundle and produce an identical conformance fingerprint. Cursor, Windsurf, and VSCodium ride the VS Code adapter. Piye native L2 adapter is in progress.
• Registry: Running at oxp.sh.
• CLI: Fully functional — create, dev, pack, publish, install, login, keygen, token rotate.
• Security: Phase A complete — WASI sandbox, install-time prompts, TOFU key pinning, scoped tokens, CSP, bundle policy enforcement.

Shipping Next (v0.2)

These capabilities are already specified in WIT and in active integration on all three hosts — they roll out as conformance tests go green, not on a fixed calendar:

• Native UI surfaces — ui/render painted into JetBrains tool windows and Neovim floating windows (today they're stashed in-memory).
• Streams — long-running stream/* RPCs for log tailing, build output, and incremental search.
• **editor/* APIs** — read selections, apply edits, decorate ranges, register code lenses.
• **surface/register** — declarative panel + view registration so one manifest entry produces native chrome on every host.

Governance

OXP's spec is intended to be donated to a neutral foundation (CNCF Sandbox or Eclipse Foundation) once three external IDE adopters ship L1 or higher. The registry and CLI remain stewarded by the OXP project; the spec belongs to the ecosystem.