RFC: Visual Extension API - Allow Extensions to Render GUI

[nguyenphutrong]

Body

RFC: Visual Extension API - Allow Extensions to Render GUI

Status: Draft
Author: Trong Nguyen
Related: #21400 (closed - unactionable), #48947 (discussion - open)
Willing to implement: Yes, I am willing to create a PR for this feature

---

1. Summary

Proposal to extend the Extension API to allow extensions to create and manage user interface components (GUI) within Zed, including sidebar panels, status bar items, and custom views.

Goals

• Enable extensions to register and display custom panels
• Allow extensions to add items to the status bar
• Enable extensions to render visual content (not just text)
• Provide a safe, sandboxed, and high-performance API

Non-Goals (MVP)

• Full webview support (GPUI-based rendering only)
• Custom editor implementations (text editor remains primary)
• Direct access to the windowing system (all access through abstraction layer)

---

2. Motivation

Problem

Currently, Zed's Extension API only supports "headless" features:

Current Feature	Limitation
Language Servers	LSP only, no custom UI
Slash Commands	Text-based, no visual feedback
Context Servers	MCP, headless
Snippets	Code templates, non-interactive
Themes	Static styling, not dynamic
Debug Adapters	Protocol-based, UI controlled by Zed

Consequences:

• Extensions cannot provide user experiences comparable to VS Code
• Ecosystem growth is limited due to UI constraints
• Users must rely on external tools for many use cases (i18n, DB management, API testing, etc.)

Use Cases

Extension Type	GUI Needs	Value
i18n Manager	Table view, edit translations	Non-technical users can translate
Database Browser	Tree view tables, query results	No external DB client needed
API Client	Request builder, response viewer	Postman/Insider replacement
Git GUI	Visual commit graph, branch view	GitKraken-like experience
Task Runner	Progress bars, output panels	Better than terminal
Color Picker	Visual color selector	Design workflow
Image Preview	Thumbnail gallery	Asset management
Plot/Chart	Data visualization	Analytics workflow

---

3. Design Principles

3.1 Constraints (Learning from VS Code)

VS Code allows extensions nearly full control, leading to:

• Laggy, crashing extensions
• Inconsistent UI
• Security risks from webviews

Zed will take a different approach:

1. Restricted API: Only provide safe, optimized components
2. GPUI-based: Use Zed's native UI framework, no webviews
3. Performance Budget: Extensions must meet frame time requirements
4. Theming Consistency: Automatically apply user theme

3.2 Architecture Overview

┌─────────────────────────────────────────────────────────┐
│                    Zed Application                       │
│  ┌─────────────────┐  ┌──────────────────────────────┐  │
│  │  Core Panels    │  │  Extension Panels            │  │
│  │  - Git Panel    │  │  ┌─────────┐ ┌─────────┐    │  │
│  │  - File Tree    │  │  │ i18n    │ │ API     │    │  │
│  │  - Terminal     │  │  │ Panel   │ │ Client  │    │  │
│  │  - Agent        │  │  └─────────┘ └─────────┘    │  │
│  └─────────────────┘  └──────────────────────────────┘  │
│                                                        │
│  ┌──────────────────────────────────────────────────┐  │
│  │           Extension Host (WASM)                   │  │
│  │  ┌──────────┐  ┌──────────┐  ┌──────────────┐    │  │
│  │  │ Extension│  │ Extension│  │   Extension  │    │  │
│  │  │    A     │  │    B     │  │      C       │    │  │
│  │  └────┬─────┘  └────┬─────┘  └──────┬───────┘    │  │
│  │       │              │               │             │  │
│  └───────┼──────────────┼───────────────┼───────────┘  │
│          │              │               │              │
│  ┌───────┴──────────────┴───────────────┴───────────┐  │
│  │         Visual Extension API (WIT)                  │  │
│  │  ┌──────────┐ ┌──────────┐ ┌──────────────────┐    │  │
│  │  │  panel   │ │  status  │ │  view components │    │  │
│  │  │  api     │ │  bar api │ │  (buttons, etc)  │    │  │
│  │  └──────────┘ └──────────┘ └──────────────────┘    │  │
│  └────────────────────────────────────────────────────┘  │
└─────────────────────────────────────────────────────────┘

---

4. Proposed API (WIT Interface)

4.1 Panel Interface

// extension-panel.wit
interface panel {
    use common.{resource, result};
    
    /// Types of panels extensions can create
    enum panel-position {
        left-sidebar,
        right-sidebar,
        bottom-panel,
    }
    
    /// Panel registration info
    record panel-info {
        id: string,
        name: string,
        icon: option<string>,  // Icon name from icon font
        position: panel-position,
        default-visible: bool,
    }
    
    /// Resource handle to a panel instance
    resource panel-handle {
        /// Update panel content
        update: func(content: element-tree) -> result<_, string>;
        
        /// Show/hide panel
        set-visible: func(visible: bool);
        
        /// Get current visibility state
        is-visible: func() -> bool;
    }
    
    /// Register a new panel
    register-panel: func(info: panel-info) -> result<panel-handle, string>;
}

4.2 Component System

// extension-components.wit
interface components {
    /// Base element type
    variant element {
        container(container-props, list<element>),
        text(text-props),
        button(button-props),
        text-input(input-props),
        table(table-props),
        list(list-props),
        icon(icon-props),
        // ... more components
    }
    
    record container-props {
        direction: flex-direction,
        gap: option<u32>,
        padding: option<u32>,
        background: option<color>,
        // ... styling props
    }
    
    record button-props {
        label: string,
        variant: button-variant,
        on-click: option<callback-id>,
        disabled: bool,
    }
    
    record table-props {
        columns: list<column-def>,
        rows: list<list<element>>,
        selection-mode: selection-mode,
        on-selection-change: option<callback-id>,
    }
    
    // ... other component definitions
    
    /// Callback system for interactivity
    resource callback-registry {
        register: func(id: callback-id, handler: callback-handler);
    }
    
    type callback-id = string;
    type callback-handler = func(args: list<variant-arg>) -> result<variant-arg, string>;
}

4.3 Status Bar API

// extension-status-bar.wit
interface status-bar {
    /// Add item to status bar
    add-item: func(item: status-item) -> result<status-item-handle, string>;
    
    record status-item {
        id: string,
        content: status-content,
        priority: i32,  // Ordering (lower = left)
        tooltip: option<string>,
        on-click: option<callback-id>,
    }
    
    variant status-content {
        text(string),
        icon(string),
        text-with-icon(string, string),
    }
    
    resource status-item-handle {
        update-content: func(content: status-content);
        remove: func();
    }
}

4.4 Extension Trait Update

// extension.wit - updated
interface extension {
    /// Called when extension should build its UI
    build-ui: func() -> ui-definition;
    
    record ui-definition {
        panels: option<list<panel-info>>,
        status-items: option<list<status-item>>,
        // ... future UI elements
    }
    
    /// Handle UI events
    handle-event: func(event: ui-event) -> result<option<element-tree>, string>;
}

---

5. Implementation Strategy

5.1 Phased Approach

Phase 1: Status Bar Items (MVP)

• Scope: Only allow adding text/icon to status bar
• Complexity: Low
• Value: Extensions can show state (e.g., "Building...", "3 tasks pending")
• Effort: 1-2 weeks

Phase 2: Simple Panels

• Scope: Read-only panels with basic components (text, buttons, lists)
• Complexity: Medium
• Value: Extensions can show information panels (e.g., file info, statistics)
• Effort: 3-4 weeks

Phase 3: Interactive Panels

• Scope: Editable content, forms, tables
• Complexity: High
• Value: Full-featured extensions (i18n editor, DB browser)
• Effort: 6-8 weeks

Phase 4: Advanced Components

• Scope: Charts, image preview, custom renderers
• Complexity: Very high
• Value: Professional extensions
• Effort: 2-3 months

5.2 Technical Challenges

Challenge	Approach	Risk
WASM ↔ GPUI bridge	Async message passing via WIT	Medium
Component serialization	Tree structure via WIT types	Low
Event handling latency	Batch events, async callbacks	Medium
Performance isolation	Frame budget, yield points	High
Theming	Auto-convert extension colors	Medium
Accessibility	ARIA metadata in WIT	Medium

---

6. Security Considerations

6.1 Sandboxing

• Extensions continue to run in WASM sandbox
• No direct filesystem access (via worktree API)
• Network access via http-client API (already exists)

6.2 UI Safety

• No arbitrary HTML/CSS allowed (prevent XSS)
• Predefined and validated components only
• Resource limits (max panel size, component count)

6.3 Performance Protection

• Frame time budget for extension rendering
• Auto-disable extension if consistently slow
• Lazy loading for inactive panels

---

7. Migration Path

For Extensions

// Before (current API)
impl Extension for MyExtension {
    fn new() -> Self { ... }
    // Only language server, slash commands
}

// After (with UI support)
impl Extension for MyExtension {
    fn new() -> Self { ... }
    
    fn build_ui(&self) -> UiDefinition {
        UiDefinition {
            panels: vec![
                PanelInfo {
                    id: "my-panel",
                    name: "My Extension",
                    position: PanelPosition::RightSidebar,
                    ...
                }
            ],
            status_items: vec![...],
        }
    }
    
    fn render_panel(&self, panel_id: &str) -> ElementTree {
        // Return component tree
    }
}

---

8. Alternatives Considered

A. WebView-based (VS Code approach)

• Pros: Easy for extension devs (HTML/CSS/JS)
• Cons: Heavy, slow, inconsistent UX, security risks
• Decision: ❌ Not chosen

B. GPUI-based (this proposal)

• Pros: Native performance, consistent UX, secure
• Cons: Harder for extension devs (must learn GPUI concepts)
• Decision: ✅ Chosen

C. React-like DSL

• Pros: Familiar for web devs
• Cons: Requires additional abstraction layer, more complex
• Decision: 🟡 Phase 2+ (if needed)

---

9. Impact Analysis

On Ecosystem

Metric	Before	After (1 year)
Extensions with UI	0%	~30%
Extension quality	Text-only	Rich experiences
User adoption	Limited	Broader use cases
Community growth	Slow	Accelerated

On Core Codebase

• New crate: extension-ui (~2000-3000 lines)
• Modifications: extension_host, workspace
• Maintenance: New API surface needs stable versioning

---

10. Implementation Commitment

I am willing to implement this feature. I have experience with:

• Rust systems programming
• WASM and WASI interfaces
• GPUI concepts (from studying Zed codebase)
• API design for extension systems

I can start with a proof-of-concept PR for Phase 1 (Status Bar API) to demonstrate feasibility before committing to the full implementation.

11. References

• Previous request: Allow Extensions to Create and Manage Customizable Side Panels #21400 (closed as unactionable)
• Community interest: Allow extensions to add buttons to a specific area of the UI #48947 (discussion - open, 8 votes)
• Similar systems:
  • VS Code: Webview API (heavyweight)
  • JetBrains: Plugin API (Swing-based)
  • Sublime: Quick panel API (limited)

[KiidxAtlas]

this is something that actually caused me to move away from zed some time ago

i loved everything about this editor... but it definitely needs much more support for extensions id even say it should definitely be even more capable than what other ide alternatives have in place.

this is something that seems to get relatively overlooked and i enjoyed using zed so much that i would definitely love to contribute and build this feature out.

[nakajimayoshi]

I'd be interested in assisting with the development of this feature as well as I've been dying for a DB viewer in Zed to fully replace my workflow in VSCode.

Some feedback on the RFC:

impl Extension for MyExtension {
    fn new() -> Self { ... }
    
    fn build_ui(&self) -> UiDefinition {
        UiDefinition {
            panels: vec![
                PanelInfo {
                    id: "my-panel",
                    name: "My Extension",
                    position: PanelPosition::RightSidebar,
                    ...
                }
            ],
            status_items: vec![...],
        }
    }
    
    fn render_panel(&self, panel_id: &str) -> ElementTree {
        // Return component tree
    }
}

This makes the assumption that all extensions need to implement a UiDefinition. As of now, none do which means it would break every existing extension unless every developer updates theirs. The semantics from a Ui are very different from that of a debugger or lsp, so an entirely new Trait that inherits Extension's methods would make sense here rather than adding it as another method in the existing trait. E.g.

pub trait UIExtension: Extension {
 fn render (&mut self, _window: &mut Window, _cx: &mut Context<Self>) -> impl IntoElement;
}

struct HelloWorld {
    text: SharedString,
}
 
impl Render for HelloWorld {
    fn render(&mut self, _window: &mut Window, _cx: &mut Context<Self>) -> impl IntoElement {
        div()
            .flex()
            .flex_col()
            .gap_3()
            .bg(rgb(0x505050))
            .size(px(500.0))
            .justify_center()
            .items_center()
            .shadow_lg()
            .border_1()
            .border_color(rgb(0x0000ff))
            .text_xl()
            .text_color(rgb(0xffffff))
            .child(format!("Hello, {}!", &self.text))
            .child(
                div()
                    .flex()
                    .gap_2()
                    .child(div().size_8().bg(gpui::red()))
                    .child(div().size_8().bg(gpui::green()))
                    .child(div().size_8().bg(gpui::blue()))
                    .child(div().size_8().bg(gpui::yellow()))
                    .child(div().size_8().bg(gpui::black()))
                    .child(div().size_8().bg(gpui::white())),
            )
    }
}

impl UIExtension for MyExtension {
    fn new() -> Self { ... }
   
    fn render (&mut self, _window: &mut Window, _cx: &mut Context<Self>) -> impl IntoElement {
        cx.create_pane(PaneOptions { 
          position: PanePosition::Left, 
          width: px(500)
        },
        |_, cx| { 
               cx.new(|_| HelloWorld {
                    text: "World".into(),
               })
        }).unwrap()
    }
}

I believe there's no better abstraction for Zed UI extensions than GPUI. It already uses a bunch of web semantics (divs, trees, etc.), is well understood by the Zed team, has documentation, and already has a components library. Writing an entirely new DSL would be a big ask for the team since they've mentioned their focus on AI features right now.

The most difficult aspect of this though is security. Simply punching in GPUI code directly into the main process eliminates Zed's entire security model and allows any UI extension developer to run native code on your machine. My two-cents is the best way to implement this would be to extend GPUI to have a serde implementation that lets subprocesses make GPUI calls over the wire via IPC. The main Zed process can sanitize any incoming calls and validate the caller's permissions.

Addendum:
WIT is probably better than IPC for cross-process communication in this instance since it's already supported by the extension api and is much faster. How GPUI components can be translated across WIT has yet to be determined.

[clementGilardy]

This RFC addresses exactly the kind of use case I've been wanting to build: a native sidebar panel that displays real-time data from external services, Linear tickets, Jira issues, AWS resources, database views, etc.

Right now the only viable path for this kind of integration is MCP, which works for AI-assisted workflows but doesn't give you a persistent, always-visible panel. A proper Visual Extension API with GPUI-rendered panels would unlock an entirely different category of extensions ones that keep external context visible alongside your code without switching apps or opening a browser.

Some concrete use cases this would enable:

• Linear/Jira panel showing tickets linked to the current branch or file
• AWS resource explorer docked in the sidebar
• Live database table viewer
• CI/CD pipeline status panel

Personally, I'm tired of the resource overhead of tools like JetBrains IDEs and I want to switch fully to Zed but that requires feature parity on the integration side. This API would be a major step toward making that switch viable for teams that rely heavily on external tooling.

I'd be happy to contribute to the implementation if the team moves forward with this. Happy to help with prototyping the WIT interface design, building a reference extension, or whatever is most useful.

[jeremycastanza]

This type of feature really needs high priority. I would say the extension piece is the one feature that's keeping myself and other developers tethered to other IDEs like Cursor or VS Code. Developers need the ability to add custom user interfaces where it makes sense to their own workflows.

I think this is a solid opportunity for Zed. One short coming with VS Code is that user interfaces really make the IDE look like a mash up of different tools. If Zed offered an opinionated UI API to be able to expose views that appear native to Zed that would be the best of both worlds.

[jeremycastanza]

if we wanted to get a small group together to work on this, what would it look like?

[luan-coelho]

After reading several discussions and issues in this repository, unfortunately it seems that a robust extensions API is still not a clear priority for the Zed team.

I currently rely heavily on JetBrains IDEs in my workflow, especially IntelliJ as my main IDE. However, I would seriously consider changing my workflow to Zed if there were better feature parity and, more importantly, a more powerful extension ecosystem.

One of JetBrains’ biggest strengths is its SDK. It allows developers to build extensions that integrate deeply with the IDE, customize important parts of the UI, add tools, panels, actions, inspections, integrations, and support very specific workflows.

In my opinion, the Zed team should reconsider its priorities in this area. Features focused on organizations, teams, or AI may be important, but they lose impact if the user base still cannot adapt the editor to real-world workflows. Before investing heavily in more advanced product layers, it may be more strategic to broaden adoption by building a strong extensibility foundation.

A more complete extensions API would not just be another feature. It could be a decisive factor in attracting users who currently depend on IDEs like IntelliJ, VS Code, or other more mature tools. The more the community can extend Zed, the more likely the editor is to grow organically and support use cases that the core team will never be able to cover entirely on its own.

[AirboZH]

I’d love to build a JSONL preview extension and a SQLite viewer extension for Zed, so having a way to create custom UI feels like the essential first step.

This feature would unlock a lot of practical extensions that currently require jumping back to VS Code or external tools.

Really looking forward to this. I’ll keep following the discussions, and I’d be happy to help if there’s anything I can contribute.

[macraig]

Hey everyone, thanks for the enthusiasm and willingness to work on this — we really appreciate it! This is closely tied to our extensions roadmap, and something that needs to be driven by our team to make sure it's done in a coherent way. It's a significant undertaking and not something we're likely to get to in the near future, but it's very much on our radar as part of the bigger extensions story. We'll update this thread as things progress!