OpenAgents Episode 26X - Forking Zed

Status: prepared script / unscheduled future-episode draft. Episode number: not assigned. This script moved off slot 263 on 2026-07-24 when Full Auto took that slot. Speaker: Sarah. Follows Episode 262 (Project Omega). Delivery: calm, precise, and technically direct. Audience: developers and technically interested OpenAgents followers. Research refresh: 2026-07-23. Omega audit commit: 30c80504403b7dcb10c7d0a476577014ebc871f6. Audited Zed fork base: 137c981cb03b38034ce727f4055f7423c051627f. Product direction: Omega implementation roadmap. Accepted architecture: Omega, the Zed-based OpenAgents IDE. Zed research: Zed teardown. Production requests: Forking Zed production requests.

This is a tour of the fork and its insertion points. At the audit commit, almost all application source is still Zed. The Omega fork delta contains the Omega README and local environment ignore rules. The tour must not present planned Omega features as implemented code.

Technical source notes

The current application still declares:

• Zed version 1.14.0
• Rust toolchain 1.95.0
• 240 crate manifests below crates
• dev.zed.* application identifiers
• Zed application-data paths
• Zed command names and links
• Zed account, collaboration, telemetry, hosted-feature, and update endpoints
• Zed signing, provisioning, artifact, disk-image, and terms assumptions

This state is the starting point for the first Omega work. It is not a release-ready Omega identity.

The source tour uses these primary paths:

• Cargo.toml
• crates/zed
• crates/gpui
• crates/workspace
• crates/project
• crates/editor
• crates/git and crates/git_ui
• crates/terminal and crates/terminal_view
• crates/remote and crates/remote_server
• crates/agent, crates/agent_ui, and crates/agent_servers
• crates/paths
• crates/release_channel
• crates/cli and crates/install_cli
• script/bundle-mac
• script/terms/terms.rtf

Production direction

Use these labels:

• OMEGA SOURCE - CURRENT for the audited fork.
• OMEGA FORK BUILD - UPSTREAM ZED IDENTITY for a build from the audited fork.
• STOCK ZED - CURRENT REFERENCE for an official stock Zed interface.
• ACCEPTED ARCHITECTURE - NOT RUNNING for planned process diagrams.
• UNSIGNED DEVELOPMENT BUILD for any unsigned local application.
• FUTURE OMEGA REPLACEMENT for a shot that needs the branded application.

Keep the repository commit visible during the source tour. Mask local usernames and paths. Do not show credentials, signing secrets, or private project names.

Assembly map

Beat	Story	Primary visual
1	The fork exists	GitHub parent line and local Git refs
2	The Rust workspace	Root Cargo.toml and crate map
3	The native product core	zed, gpui, workspace, project, editor
4	Daily developer tools	Git, terminal, remote, and agent crates
5	What must change first	Branding, paths, endpoints, and package scripts
6	Where OpenAgents enters	Rust and Effect process diagram
7	Port order	Desktop parity and workroom sequence
8	First release	v0.2.0-rc1 gate and closing commit

Treat the time order as editorial. Do not read source files line by line. Use each file to explain one design boundary.

---

[OPEN ON A TERMINAL IN THE OMEGA CHECKOUT.]

[Run: git remote -v git rev-parse HEAD git merge-base HEAD upstream/main

Keep remote URLs and commit values readable. Mask the local path.]

[TEXT OVERLAY: OPENAGENTS EPISODE 263 FORKING ZED]

Sarah: The fork already exists.

Now let us look inside it.

Omega is not an editor extension.

It is not an Electron wrapper.

It is not a product mockup.

Omega is a tracked fork of Zed.

An extension cannot own the complete application identity. It cannot fully own native panes, processes, storage, updates, or release artifacts.

Omega needs that complete product boundary.

[CUTAWAY - CAPTURE NOW: show OpenAgentsInc/omega, the forked from zed-industries/zed line, and the commit history.]

At this audited commit, Omega is 30c8050.

Its recorded Zed fork base is 137c981.

Most of the application source is still Zed.

The visible Omega delta is small: the new README and local environment ignore rules.

That is not a secret.

It is the point of the starting line.

[TEXT OVERLAY: TODAY: A TRACKED ZED FORK NEXT: A BRANDED OMEGA BUILD]

[CUTAWAY - CAPTURE NOW: from the clean audited checkout, run: cargo run --profile release-fast Record the command, commit, toolchain, result, and application launch. Label the application OMEGA FORK BUILD - UPSTREAM ZED IDENTITY and UNSIGNED DEVELOPMENT BUILD when applicable.]

Before we change the product, we prove the inherited source can build and launch from our fork.

That gives every later change a known baseline.

Forking gives us the right to change the product.

It also gives us responsibilities.

We must preserve the applicable licenses and attribution. Our release plan publishes the exact corresponding source for every distributed Omega build. We must record the upstream commit and our patch series. We must keep learning from Zed without letting upstream changes silently break Omega.

[CUTAWAY - CAPTURE NOW: show the repository license files, Git remotes, and a simple upstream-to-Omega commit diagram.]

[TEXT OVERLAY: PIN THE SOURCE TRACK UPSTREAM PRESERVE ATTRIBUTION PROVE THE BUILD]

Now open the root Cargo.toml.

[CUTAWAY - OMEGA SOURCE - CURRENT: open Cargo.toml. Show the workspace, members, shared dependencies, and default application member.]

Zed is a large Rust workspace.

The application is not one enormous crate. It is a system of focused crates.

The workspace has 240 crate manifests below crates. Its pinned Rust toolchain is 1.95.0.

That is useful for Omega.

We can identify the existing owner for an editor behavior. We can add a bounded OpenAgents seam. We can test that seam. We do not need to replace the whole application to change one product domain.

[TEXT OVERLAY - architecture card: APPLICATION - crates/zed NATIVE UI - crates/gpui SHELL + PANES - crates/workspace PROJECTS - crates/project EDITING - crates/editor]

The application starts in crates/zed.

Open crates/zed/src/main.rs.

[CUTAWAY: show the file and then move to crates/zed/src/zed.rs. Do not scroll through initialization code for more than a few seconds.]

This is the bootstrap and composition layer.

It creates the application. It connects platform services. It loads the product crates.

Omega will change this composition over time.

But the first goal is not to tear it apart.

The first goal is to give the existing application a correct Omega identity, then prove it can build and launch.

Next is GPUI.

[CUTAWAY: open crates/gpui/README.md and then crates/gpui/src. Show a clean local Zed window beside the source.]

GPUI is Zed's Rust user-interface framework.

It owns native windows, rendering, input, layout, and application entities. It mixes immediate and retained user-interface patterns.

For OpenAgents, this matters because the workroom does not need to be a web page inside an editor.

Workrooms, agent rosters, approvals, run monitors, and receipts can become native panes.

[TEXT OVERLAY: NATIVE GPUI PANES NOT AN EMBEDDED WEB APP]

[CUTAWAY: open crates/workspace/src/item.rs and crates/workspace/src/pane.rs. Highlight the Item and Pane contracts.]

Editors, terminals, and diffs use the workspace item and pane contracts.

An Omega workroom can use those same contracts. It can participate in tabs, focus, splits, navigation, and restoration.

GPUI is also a moving dependency. Its public interface is still pre-1.0.

Omega must track upstream changes instead of freezing an old private copy.

Now look at the daily editor surface.

[CUTAWAY: open these directories in sequence: crates/workspace crates/project crates/editor]

workspace owns the application shell and pane composition.

project owns the relationship between the application and a project.

editor owns buffers, selections, navigation, and the editing experience.

These crates are why Project Omega is different from another zero-base reset.

OpenAgents does not need to spend its first months rebuilding files, tabs, splits, buffers, search, language tooling, and project restoration.

Those capabilities already exist.

We can use them while we build the OpenAgents product above them.

[CUTAWAY - quick montage only: move through crates/language, crates/multi_buffer, and crates/editor. End on crates/project/src/project.rs.]

Versioned buffers, excerpts, diffs, and editor views share exact identities and revisions.

The project layer connects them.

[CUTAWAY: open crates/project/src/project.rs. Highlight the worktree, buffer, language-server, Git, task, terminal, debugger, context-server, and agent-server stores.]

Zed already has one project graph where files, buffers, language tools, Git, terminals, tasks, and agents agree about the project.

Now move to Git.

[CUTAWAY: show crates/git, crates/git_ui, the Git Panel, and Project Diff.]

Zed already has native Git state and review surfaces.

Omega can connect agent work to exact files, versions, diffs, worktrees, reviews, and commits.

Zed remains the owner of buffer and worktree truth.

OpenAgents adds the work record: who requested the change, which agent performed it, what evidence exists, who approved it, and which receipt closes it.

[TEXT OVERLAY: ZED: FILE + GIT TRUTH OPENAGENTS: WORK + EVIDENCE TRUTH]

The terminal follows the same principle.

[CUTAWAY: show crates/terminal, crates/terminal_view, a split terminal, and an editor link opened from terminal output.]

We inherit a real terminal, tasks, links, splits, and project integration.

We do not port the web terminal from the current Electron application.

We connect OpenAgents work to the native terminal that is already here.

Remote development is already part of the source too.

[CUTAWAY: show crates/remote, crates/remote_server, and the first-party Zed remote-development documentation.]

Zed can keep the responsive interface local while project work runs through a remote server.

That gives Omega a strong base for local and managed execution.

It does not automatically grant portable-session or cloud authority. OpenAgents still has to preserve identity, capability, version, and receipt rules across that boundary.

Now open the agent crates.

[CUTAWAY: show: crates/agent crates/agent_ui crates/agent_servers/src/acp.rs crates/agent_servers/src/custom.rs]

Zed already supports native agent threads. It supports external agents through the Agent Client Protocol. It also supports custom agent commands and terminal threads.

ACP connects an agent runtime to the host. MCP supplies tools and context. An MCP server is not automatically a complete agent.

This is an important starting boundary.

An external agent can keep its runtime, authentication, model, tools, skills, instructions, and MCP configuration.

The editor can host the thread and review surface.

Omega will extend that model.

Episode 262 made the product promise. Here it becomes an ACP or explicit-adapter boundary.

Show exactly what the adapter can do. Show exactly what it cannot do.

Do not create a second agent home. Do not copy credentials. Do not flatten every agent into one generic bot.

[TEXT OVERLAY: THE AGENT OWNS ITS RUNTIME OMEGA OWNS THE WORK SURFACE]

Those are the parts we inherit.

Now we reach the first Omega changes.

Open crates/zed/Cargo.toml.

[CUTAWAY: highlight the current version, bundle names, bundle IDs, icons, and URL schemes.]

The application still reports Zed version 1.14.0.

Its bundles still use Zed names and dev.zed.* identifiers.

Open crates/paths/src/paths.rs.

[CUTAWAY: highlight APP_NAME and the comment that tells forks to change it.]

The application name is still Zed.

That means a careless first launch can use Zed data paths.

Omega must change this before a branded release.

Open crates/release_channel/src/lib.rs.

[CUTAWAY: show current display names, application IDs, and documentation URLs.]

The release channels still identify Zed.

Open crates/cli/src/main.rs and crates/install_cli/src/install_cli_binary.rs.

The command, help text, application discovery, paths, and installation flow still identify Zed.

These are not cosmetic details.

Application identity controls which data, credentials, protocols, update state, and installed application a user touches.

[TEXT OVERLAY: BRANDING IS ALSO DATA ISOLATION]

The endpoint audit matters too.

A fresh Omega profile must not silently contact Zed account, collaboration, telemetry, hosted-agent, or update services.

If an upstream service remains available, the interface must name it honestly. Omega must not present a Zed service as an OpenAgents service.

The first release needs a separate data root, separate application ID, separate protocol name, and disabled unsupported services.

Then comes packaging.

Open script/bundle-mac.

[CUTAWAY: highlight the current Zed signing identity, artifact names, disk image name, provisioning assumptions, and Sentry upload. Then show script/terms/terms.rtf. Do not reveal any credential value.]

The inherited bundle script is a Zed release script.

It uses Zed signing assumptions. It emits Zed-named artifacts. It contains Zed service and crash-reporting paths. Its disk image includes Zed commercial terms.

Omega needs its own package path.

The first public candidate must use OpenAgents identity, correct licenses, published source, a signed and notarized application, and an honest limitation notice.

An unsigned local build is development evidence. It is not a public release candidate.

[TEXT OVERLAY: OMEGA v0.2.0-rc1 MACOS APPLE SILICON SIGNED + NOTARIZED BOOTSTRAP CANDIDATE]

That explains the native repository.

Now we need to connect it to OpenAgents.

[CUTAWAY: open crates/node_runtime/src/node_runtime.rs near the runtime lifecycle.]

Zed already has a Node runtime abstraction.

Omega can learn from its lifecycle. Omega will not use its dynamic download path for the authority service.

The planned OpenAgents service uses a fixed packaged Node 24 component. Rust supervises that exact component.

[CUTAWAY: split screen. Left side shows the Omega repository. Right side shows the OpenAgents monorepo packages and Effect services. Then replace both with a simple architecture card.]

[TEXT OVERLAY - architecture card: OMEGA REPOSITORY RUST + GPUI CLIENT

OPENAGENTS MONOREPO TYPESCRIPT + EFFECT SERVICES

PRIVATE VERSIONED LOCAL PROTOCOL

Footer: ACCEPTED ARCHITECTURE - NOT RUNNING]

Omega owns the native client.

The OpenAgents monorepo owns reusable TypeScript packages, Effect services, schemas, generated clients, and conformance fixtures.

The first integration can package a Node 24 service beside the Rust application.

That service does not exist in Omega today.

Omega supervises that service. The two processes use one private, generated, versioned protocol.

This is not a general local web server. It does not expose raw filesystem or process authority.

The service boundary lets us move current OpenAgents Desktop behavior without rewriting every domain at once.

Then we can move suitable domains to Rust one by one.

A Rust port is complete only when behavior, state, recovery, and receipts still match.

[TEXT OVERLAY: PORT ONE AUTHORITY AT A TIME PROVE PARITY REMOVE THE OLD PATH]

The product migration follows a clear order.

First, start and supervise the shared OpenAgents runtime.

Second, complete one real Codex turn in a native Omega agent surface.

Third, move conversations, history, queue, steer, stop, questions, approvals, and agent activity.

Fourth, bind canonical identity, Sync, and mobile continuity.

Fifth, move Full Auto.

Sixth, connect agent work to native projects, buffers, Git, terminals, and review.

Then complete settings, providers, portable execution, migration, and parity.

Only after current Desktop parity do we add the broader workroom program.

[TEXT OVERLAY - sequential: RUNTIME ONE AGENT CONVERSATIONS SYNC + MOBILE FULL AUTO NATIVE CODE REVIEW DESKTOP PARITY WORKROOMS]

The Buzz lesson enters there.

We are not importing another server, relay, forge, Tauri shell, or Flutter client.

We are building native GPUI panes for workrooms, attention, threads, people, agents, work, and receipts.

We attach existing agents before we add broad social features.

Nostr comes later as optional interoperability. It does not become the company database or command authority.

That is the codebase.

It is large because a serious editor is large.

That size is not a reason to rebuild it.

It is the accumulated product work we chose to begin with.

Forking Zed gives Omega a serious editor foundation on day one.

It also gives us a serious responsibility.

Keep the fork healthy. Preserve attribution. Track upstream. Prove every boundary we add.

The tour is over.

Now we start changing the product.

[END CARD: FORKING ZED NEXT: OMEGA v0.2.0-rc1 BRAND -> BUILD -> SIGN -> VERIFY -> RELEASE github.com/OpenAgentsInc/omega]