Nothing to the cloud: how OIOXO's bridge gives a browser your machine's power

A browser tab is a wonderful place for an IDE — zero install, always current, sandboxed. It's also, by design, cut off from the best parts of your machine: the real language servers you've installed, your shell, your git, your GPU-warmed local model. The usual industry answer is to move the machine to the cloud instead — host the workspace, tunnel the traffic, keep a copy of your repo on someone's server.

We went the other way. The OIOXO bridge is one command:

oioxo bridge

It starts a small relay that listens on 127.0.0.1 — the loopback address, reachable only from your own machine — and the web IDE at oioxo.com quietly detects it. From that moment, the tab stops being a sandbox with a model in it and becomes a front-end to your actual computer. The traffic never crosses the internet: browser to loopback, loopback to your tools. Nothing goes to the cloud, because there is no cloud in the path at all.

What the bridge lends the tab

• Real language servers. If you have pyright, rust-analyzer, or gopls installed, the web IDE's diagnostics, hovers, and symbols come from them — the same engines your desktop editor uses — instead of the in-browser approximations. Cross-file rename and find-references included.
• A real debugger. Breakpoint debugging is relayed over the Debug Adapter Protocol to native debuggers on your machine.
• Your shell. The agent's run-and-verify loop can execute real commands — your test runner, your build — instead of only the in-browser runtimes.
• Your git. Local history, branches, and commits on the real repo on your disk.
• Your model. This is the newest piece: if you've already installed an on-device OIOXO model (for example via oioxo code --local), the bridge relays that engine to the tab. The browser reuses the model on your disk — served by the local engine, often GPU-accelerated — instead of downloading its own copy into browser storage. One model, every surface.

The web IDE degrades gracefully: no bridge, and everything falls back to the in-browser engines. The bridge adds power; it's never required.

The security posture, plainly

"Local relay" should make a security-minded reader pause, so here is exactly how it's built:

• Loopback only. The bridge binds to 127.0.0.1. It is not reachable from your network, let alone the internet.
• A session token on every call. Detection hands the page a token, and every privileged request must present it. A random website can't just guess its way into your shell.
• Origin checks. CORS restricts which origins may talk to the bridge, and it participates in the browser's Private Network Access handshake — the mechanism Chrome uses to gate public-website-to-localhost requests.
• One discovery path. The web app probes for the bridge through a single, short-timeout detection routine with negative caching — machines without a bridge see no delay and no probe spam.

And the property that motivated all of it: OIOXO's servers are not involved. The bridge is not a tunnel through us. We can't see your language-server traffic, your shell output, your diffs, or your prompts, because none of it ever leaves the loopback interface. Our servers still do exactly two jobs — accounts and fair-use metering — same as always.

Why this architecture matters

Every cloud IDE eventually asks you to accept the same sentence: "your code is on our machines, but we promise to be careful." The bridge exists so that sentence never has to be said. The browser brings the interface; your machine brings the power; the connection between them is three centimeters of loopback.

If you have the CLI installed, try it: run oioxo bridge, open the IDE, and watch your own computer show up as the engine. That's the whole trick — there isn't one.