OpenAI's OWL puts Chromium in a separate process so Atlas can be a native SwiftUI app

The inversion: Chromium as a service, not the shell

Most Chromium-derived browsers ship the engine and its UI together, then reskin the parts users see. OpenAI took a different route with Atlas. Its architecture layer, OWL (OpenAI's Web Layer), runs Chromium's browser process outside the main Atlas app process entirely, in what the authors call an isolated service layer.

They frame it as extending a move Chromium already made: Chromium put tabs in separate processes, and OWL puts Chromium itself into a separate process. The Atlas app becomes the OWL Client; the Chromium browser process becomes the OWL Host. The two talk over Mojo, Chromium's own message-passing system, with custom Swift and TypeScript bindings so the Swift app can call host-side interfaces directly.

That client library exposes a small Swift API around concrete concepts — Session, Profile, WebView, WebContentRenderer, and LayerHost/Client — plus endpoints for bookmarks, downloads, extensions, and autofill. In practice the web engine is addressed as a backend, not inherited as a framework.

What this buys the frontend team

The payoff OpenAI emphasizes is native UI freedom. Because they aren't building on Chromium's open-source UI, Atlas is written almost entirely in SwiftUI and AppKit, with Metal for the rich animations the design team wanted for features like Agent mode. One language, one stack, one codebase.

Process separation also decouples failure and startup. Chromium boots asynchronously in the background while pixels reach the screen nearly instantly; if Chromium's main thread hangs or crashes, Atlas stays up. And because their diff against upstream Chromium is smaller, integrating new Chromium versions is less painful.

There is a developer-experience motive too, tied explicitly to OpenAI's culture. OWL ships internally as a prebuilt binary, so most engineers never build Chromium from source — Atlas builds take minutes, not hours.

Every new engineer makes and merges a small change in the afternoon of their first day. We needed to make sure this was possible even though Chromium can take hours to check out and build.Montana Labs

Crossing the process boundary: pixels and input

The interesting engineering is in how a native UI embeds content rendered in another process. WebViews are swapped in and out of a shared compositing container. On the Chromium side that container is a gfx::AcceleratedWidget backed by a CALayer; OWL exposes that layer's context ID to the client, where an NSView embeds it using the private CALayerHost API. Special cases like select dropdowns and color pickers, rendered by Chromium in separate popup widgets, use the same delegated rendering path.

Input runs the reverse trip. Chromium normally translates macOS NSEvents into Blink's WebInputEvent model itself; because Chromium is hidden in another process, OWL does that translation in the Swift client and forwards already-translated events down. Unhandled events come back, get re-synthesized as NSEvents, and the rest of the app gets a chance to handle them.

OWL also reuses the projection technique to pull selected pieces of Chromium's own native Views UI into Atlas — a pragmatic way to stand up permission prompts without rebuilding them in SwiftUI. The authors note this borrows from Chromium's existing infrastructure for installable web apps on macOS.

Agent mode is where the architecture earns its isolation

The separation isn't only about UI polish; it shapes how the agentic browsing feature behaves. OpenAI's computer-use model expects a single screen image, but popups like select dropdowns render in separate windows outside a tab's bounds. In agent mode, Atlas composites those popups back into the main page image at the correct coordinates so the model sees one coherent frame.

Security follows from the same boundary. Agent-generated events are routed directly to the renderer, never through the privileged browser layer, so automated input can't synthesize keyboard shortcuts that drive the browser outside the web content. And agent sessions can run in an ephemeral logged-out context using Chromium's StoragePartition to spin up isolated in-memory stores — each session starts fresh, discards cookies and site data when it ends, and multiple sessions stay isolated from one another.

The implication: agent safety was designed into the process model, not bolted on

The lesson worth taking from OWL is that Atlas's agent guarantees — the model sees the full page, automated input stays inside the sandbox, logged-out sessions can't leak state — are consequences of a rendering and process architecture chosen up front, not filters added later.

For teams building agentic products on top of complex third-party runtimes, that ordering matters. OpenAI decoupled the engine from the app first, then used that boundary to enforce where automated events can go and where session data lives. The compositing, the Mojo bindings, and the StoragePartition isolation are all the same decision expressed at different layers: treat the powerful, opaque component as a service you drive, so you control the seams where an agent touches it.