JUWEL

The browser is becoming the OS

The thesis is no longer fringe: the browser is turning into the operating system where AI works alongside you. In 2025–26 the whole field moved at once — and the most credible builds are Chromium forks, not extensions, because only a fork can rewrite the new-tab, the omnibox, permissions, and the agent's reach into the page.

BrowserOSOSS Chromium fork · agents native

Perplexity Cometagentic browser

OpenAI AtlasChatGPT-in-browser

The Browser Co · DiaAI-first browser

Opera Neonagentic

Brave / Chromeforks + native auto-browse

JUWEL's bet is the same shape — and the structure is proven: a browser half (the Chromium fork) and an agent half (the platform that drives it). We add a third half: the proof half.

The category's open wound is our wedge

Handing an autonomous agent your logged-in sessions is the whole value — and the whole danger. The field already has its first injuries: prompt-injection from malicious page content, agents taking actions the user never authorized, a court injunction, named browser vulnerabilities. The reflex answer is "trust our guardrails." JUWEL's answer is different: don't trust us — verify.

Every other agentic browser

The agent acts. The log of what it did lives with the vendor — the same party you'd be auditing.
A poisoned page can steer the agent; the user finds out after the action, if at all.
"Did it really only do that?" has no answer you can check — you take their word.

Every action is wrapped in a signed receipt — navigate, click, type, submit, pay — chained so nothing can be removed.
The verifier is not us. Run npx @vextlabs/stoa-verifier offline, flip one character, watch it fail.
Injection or overreach still leaves a tamper-proof trail — provable, not deniable.

How it's built

Four layers in the app, plus a fifth that sits across all of them — the receipts bus — and a verifier that lives outside the system entirely. That externality is the point: the thing that checks JUWEL is not part of JUWEL.

Who's driving

You + JUWEL + the Hive

Plain-language intent. Humans never have to click — JUWEL and her specialists do the operating; you approve what matters.

Layer 1 · Surface

JUWEL Shell — the OS that replaces new-tab

The dock, apps, command bar, approvals. This is the prototype already built. In the fork it is the home, the new-tab, the default surface.

new-tab overrideomnibox → command bardock / appsapproval cards

Layer 2 · Action

Agent platform

The agent loop + the Hive of specialists, driving real pages through the engine. Tools exposed over MCP so any model can operate the browser.

agent loopMCP serverCDP controllerlogged-in sessions

Layer 3 · Engine

Chromium fork (+ patches)

A maintained fork — not an extension. Patches rewrite new-tab, omnibox, permissions, and add the action-tap that feeds the receipts bus. Imports Chrome profile; all extensions run.

chromium_patchesprofile importextension compatauto-update channel

Across every layer

STOA receipts bus

Every consequential action — from any layer — is intercepted, described, and signed (ECDSA-P256) + Merkle-chained before it commits. Already real in the prototype.

↓ emits to a place we don't control

The verifier · external & open

npx @vextlabs/stoa-verifier ./receipt.json

Installs like a browser. Takes over like an OS.

No migration, no leap of faith. The first run is indistinguishable from switching browsers. The takeover is gradual and reversible — which is exactly why people will actually cross over.

STEP 01

Download JUWEL

One installer, Mac/Win/Linux. It's a real browser — nothing exotic to learn.

STEP 02

It's Chromium

Imports your Chrome profile — tabs, passwords, extensions. Everything you had still works on day one.

STEP 03

JUWEL takes the home

New-tab and the omnibox become the JUWEL shell — the dock, the apps, the agent. The OS, inside the browser you already trust.

STEP 04

Full-screen = your OS

Set default + run standalone/kiosk and the browser chrome disappears. Now it's just JUWEL — per-customer, no VM per seat.

Two builds, one brain

The same agent, the same receipts, two radii of reach. Most work lives in the browser; the rest needs the whole machine.

SKU 1 · ships first

JUWEL OS — the browser

The Chromium fork. Agents run locally, inside your real, logged-in sessions — so they can actually do the work that remote computer-use agents can't: your email, your dashboards, your company tools.

Reach: anything on the web. Every click and submit signed. This is the wedge — install it and you're in.

SKU 2 · the extension of reach

JUWEL Cursor — the computer

Computer-use beyond the page. When a task escapes the browser — a native app, the file system, the desktop — JUWEL Cursor drives the machine itself, with the same approval gate and the same signed receipts.

Reach: the whole OS. The browser is the front door; Cursor is the rest of the house.

Why a fork — and not an extension

Reach

An extension is sandboxed and can be throttled by the host browser at any update. A fork lets the agent see and drive the page through CDP at the engine level — no permission theater, no surprise breakage.

The surface

Only a fork can replace the new-tab and omnibox with the JUWEL shell, and restyle the whole chrome. The OS feeling — dock, apps, takeover — is impossible from inside an extension's box.

The proof

The receipts tap has to sit below the agent, where actions actually commit — so nothing can act without being signed. That interception point only exists in a fork you control.

It's more work than an extension and that's the moat: the credible builds in this category are forks for exactly these reasons. We inherit a proven structure and add the proof layer.

The build, in phases

Already real in the prototype

Native engineering to build

P0Weeks

Fork boots, shell is home

Stand up the Chromium fork with auto-update; patch new-tab + omnibox to load the JUWEL shell. Profile import. The OS we've designed renders as the browser's home surface.

fork · patches shell exists

P1The wedge

Agent drives pages, every action signed

Wire the agent loop to CDP; expose tools over MCP. Tap the action layer so every navigate/click/type/submit emits a STOA receipt. Inline verify on each. This is the shippable product.

CDP · MCP receipts engine exists verifier exists

P2Reach

JUWEL Cursor — computer use

Desktop build that drives native apps and the file system under the same approval + receipt model. Browser stays the front door; Cursor handles what escapes it.

computer-use approval + receipts shared

P3Network

Agent store + shared, verifiable runs

Publish/extend specialists in the Hive; share a run as a bundle of receipts anyone can verify offline. The audit trail becomes a distribution surface.

marketplace Hive exists

What's honest to say today

Real, now

The shell, the dock and apps, the Hive, the signed-receipt engine (real ECDSA-P256 + Merkle chaining), and the offline verifier with tamper-to-fail — all live in the prototype. The product design of the browser-OS is done.

Native build, next

The Chromium fork itself, the CDP/MCP agent bindings, and computer-use are C++/systems engineering — not yet built. This document is the blueprint that scopes them. We claim the design and the proof layer; we don't yet claim the fork.

A browser anyone can ship. A receipt you can check.