DEV Community: Mohamed Ibrahim

Why are we still writing separate extensions for VS Code, JetBrains, and Zed?

Mohamed Ibrahim — Sat, 23 May 2026 08:43:02 +0000

I got tired of the fact that every time a developer wants to launch a tooling product, they have to write it three separate times: once in TypeScript for VS Code, once in Java/Kotlin for JetBrains, and again in Rust for Zed.
It feels like an absolute waste of engineering hours. The IDE landscape has evolved, but the way we build extensions is stuck in a fragmented past.

To try and solve this for myself, I've spent the last few months building OXP (Open Extension Protocol). It’s an open source infrastructure layer designed to let you build an extension once and run it across any host editor.

How the Architecture Works Under the Hood: Instead of trying to map complex, bloated editor's specific APIs directly, OXP decouples the extension from the host entirely:

The Component Model: Extensions are compiled into WebAssembly (WASM) components using WebAssembly Interface Type (WIT) files to define strict boundaries.

The Communication Layer: A JSON RPC protocol handles the asynchronous communication bridge between the isolated WASM guest runtime and the native IDE host adapters.

Sandboxed Execution: Because the plugins run in a lightweight WASM sandbox, a buggy or malicious extension can't crash the entire editor thread, leak memory, or steal local environment variables.

The Current State & The VSX Wedge: Right now, I have host adapters running for VS Code and JetBrains.

To bridge the "chicken and egg" ecosystem problem, I’ve also been hacking on an internal translation layer. Using a jco backend to execute JavaScript from WASM components inside a background Node process, I’m building a compatibility shim that intercepts require(vscode) calls from standard Open VSX .vsix packages.

By mapping basic namespaces (window.showInformationMessage, workspace.fs, commands), I can get about 20% of existing, lightweight VS Code utilities running natively inside JetBrains right now. The other 80% the heavy language servers and complex WebViews is the long term mountain to climb.

Where I Need Your Brutal Feedback: This is a massive undertaking for a solo developer, and the WIT boundary definitions are incredibly tricky to get right. I would love to hear from other tool authors or engine developers:

Is the performance and UI rendering overhead of a universal JSON RPC/WASM layer too high a price to pay for cross platform portability?

What core editor APIs should be prioritized next in the WIT definition to make this genuinely useful for your workflow?

The codebase is completely open, and I’d appreciate your realistic, brutal architectural critiques.

Repo: https://github.com/oxprotocol/OXP

OXP – Write one WASM extension, run natively in VS Code, JetBrains, and Neovim

Mohamed Ibrahim — Sat, 16 May 2026 08:13:30 +0000

Hi Folks,

I’m the solo developer behind OXP (Open Extension Protocol).

I built this out of pure frustration.

Like many of you, I was tired of the fragmentation in the IDE tooling space. Building an extension meant maintaining separate codebases in TypeScript, Java/Kotlin, and Lua. Worse, in editors like VS Code, we are forced to rely on iframes and webviews for UI, which feel sluggish and disconnected from the native editor experience.

OXP is my attempt to fix this. It’s an open-source protocol and host layer that lets you write an extension once (using React and WebAssembly) and run it natively across major code editors.

How it works under the hood:

WASM Sandboxing: Extensions are bundled as a single .oxp file and run securely via WASI Preview 2. This isolates the extension and forces explicit permission requests for network or file access.

Zero-Latency IPC Bridge: Instead of running a webview, OXP translates your extension's actions directly into native IDE commands. It hooks directly into the native VS Code API, and for JetBrains, it uses JCEF to render as a native OS window.

MCP Routing: I also built in a system-level router for the Model Context Protocol (MCP). If you use AI tools like Cursor or Copilot, you can configure your database or local context once via OXP, and it instantly wires that context across all detected IDEs on your machine.

The Current State:

My goal is to make this a community-driven standard. If you are interested in tooling, WASM, or just want to tell me why my IPC bridge implementation is flawed, I would deeply appreciate your feedback.

I’ve optimized the repo so you can spin up a "Hello World" cross-editor extension locally in about two minutes.

I’ll be here all day to answer questions, explain the architecture, or take your brutal feedback. Thanks for looking!

Repo: https://oxp.sh/docs
Docs: https://github.com/oxprotocol/OXP

I spent months fighting VS Code webviews, so I built an open source universal extension protocol

Mohamed Ibrahim — Thu, 14 May 2026 00:49:59 +0000

Hey Folks,

This project started because I simply wanted to build a new IDE to fix my own workflow bottlenecks. But I immediately hit a brick wall trying to build the tooling for it. I spent months, days, and nights trying to hack and fix VS Code extension webviews just to get a decent UI to render.

I realized I was fighting a 33 year old architectural problem: extension vendor lock in. If you want your dev tool to reach people today, you have to write Electron/TypeScript for VS Code/Cursor, and Kotlin/JVM for JetBrains.

So I stopped building the IDE, and I built the fix instead.

Meet OXP (Open eXtensions Protocol).
OXP is an open source universal standard that lets you write your extension once in React/WASM and run it natively across every major editor.

How I fixed the Webview problem:
This isn't a slow iframe hack. OXP uses a secure WebAssembly sandbox and a zero-latency IPC bridge. Your React code triggers an action, and OXP translates it to native IDE commands.

In VS Code, it binds directly to the native extension API.

In JetBrains, it uses JCEF to render as a native floating OS window.
You get blazing fast native speed from a single codebase.

**The Accidental MCP Fix:

While building this universal host layer, I realized OXP perfectly solves the current Model Context Protocol (MCP) configuration hell.

Instead of manually editing configurations for Cursor, Copilot, and JetBrains individually, OXP acts as a system level MCP router. If you run oxp install @modelcontextprotocol/server-postgres, the OXP daemon instantly wires that database context into the AI configurations of every detected IDE on your machine.

I'm opening up the infrastructure today. The CLI is live, and you can test it on your machine right now.

Initialize your environment: npm i -g @oxprotocol/cli
Architecture and Docs: https://oxp.sh

I'll be in the comments all day to talk about the WASM bridge, IPC latency, fighting with JCEF, and why extension silos need to die.