Cody McCodeface
An AI coding agent, in a headset.
Drive opencode from an Apple Vision Pro — real terminals, live
diffs and as many windows as you want, sitting beside your other apps rather than taking over the room.
Nothing to install on the Mac: it speaks to stock opencode web over its own HTTP API.
Yes, the name is a Boaty McBoatface joke. No, that is not the interesting part.
// the whole architecture Vision Pro app (Swift) ──HTTP + password──▶ opencode web ← stock opencode, on your Mac # which means this is genuinely all the setup there is: OPENCODE_SERVER_PASSWORD='something long' opencode web --mdns --port 4096
Walk around it first
The app itself, in demo mode: the same windows as the headset, at the same sizes, in the same arc. Drag to look around, click a window to find out what it is. On a Quest, Enter VR is real. Pair it with a Mac (the QR code in the Mac app) and the same windows go live over WebRTC — on a phone it becomes the phone app.
Open the app → · Live once a Mac is paired; nothing in it is pretend.
What it does
All of it built and running today, on the Vision Pro.
Other headsets
The renderer is the only platform-specific half. Everything under it — the agent bridge, the
protocol, the spatial maths, the hand tracking — is plain Swift with no RealityKit in it and its own unit
tests. Porting means writing a renderer, not an app. clients/web/ already holds the reference
protocol client that the native ones were ported from.
Why native, rather than WebXR on the Vision Pro
Safari on visionOS only offers immersive-vr, which hides every other app —
including the Mac Virtual Display you are probably working next to. A native app's windows coexist with
everything else, and get system text rendering and dictation for free. That is the entire reason this is Swift.
Get started
You need a Mac with opencode on it and an Apple Vision Pro. There is no account, no cloud, and nothing of yours leaves your own machine — the headset talks to opencode directly.
The one-line version
On the Mac. That is the whole server side.
OPENCODE_SERVER_PASSWORD='something long' opencode web --mdns --port 4096
--mdns advertises it over Bonjour so the headset finds it
by itself. Set the password. Without one, anyone on your network can drive the agent and open a shell on
that Mac. In the app: Add Server → pick your Mac → enter the password.
Encrypted, using only what macOS ships
opencode web serves plain HTTP, so on a network you do not fully trust the password
crosses it in the clear. This keeps opencode on loopback and puts the Apache that is already on your Mac in
front of it for TLS, with the certificate pinned from the setup link:
tools/serve-lan.sh # loopback opencode + TLS + Bonjour + a one-tap setup link tools/serve-p2p.sh # paired peer-to-peer over the AirDrop radio — no shared network at all tools/tunnel.sh # a Cloudflare tunnel, for when you are somewhere else entirely
Or the Mac app, which is the scripts without a terminal
A window and a menu-bar icon: pick Peer-to-peer, Local network, Internet tunnel or Plain, press Start. It runs opencode through your login shell so MCP servers see your PATH, shows the pairing code, and stops everything it started when you quit. It is also what adds window streaming, the Persona camera, sandboxed workspaces and the disk explorer — none of which stock opencode can do.
It stays optional. Everything in the first section above works against stock
opencode web with nothing else installed; the Mac app only adds what needs a Mac-side process.
Roadmap
Every bug and feature anyone has asked for, ranked by the points on it. Points are staked, not spent — they come back when an item resolves, whether it ships or gets turned down. This is the real order of work, in public, not a promise about dates.
Ask for something
Proposing costs nothing. You only need points to back it.
People
Ranked by points staked — never by points held, never by money spent. Opt-in, so plenty of backers are not listed. Backed & shipped counts items someone put points on that were built.
Where points come from
One purchase, then they are yours to move around for as long as you have an account. In the
headset app they are an in-app purchase instead — same points, same account, same roadmap. A bug report with a
clean reproduction, a crash log that leads somewhere or a merged pull request earns them too; email
josh@codymccodeface.com. A roadmap only steerable by people with spare cash is a worse roadmap.
Test mode. Payments here go to a Stripe test account: no card is charged. Use Stripe's test card 4242 4242 4242 4242 with any future date and any CVC.
Cody's relay, by the month
A plan covers the relay (Cody's TURN servers, for a connection that works from anywhere) with its bandwidth package. Points are separate, and stay yours either way.
How it works, completely
You buy points once. They are yours from then on. Nothing expires, nothing decays, no subscription. The app is a one-time purchase and the points are separate from it.
You stake them on items. As many as you like, on as many things as you like, moved whenever you change your mind. Staked points are still yours — committed, not spent.
They come back when the item resolves. Shipped or declined. If points only returned on shipping, the rational move would be to pile onto whatever was nearly finished in order to get your stake out, and the board would only ever report what was almost done — which I already know. Returning them on a decline is what lets me say no to an idea without it costing the person who asked.
They are never burned. Burning makes every vote a purchase, and shrinks a long-standing customer's influence towards nothing exactly as their investment in the thing grows.
Holding is not punished. No fee, no decay, no expiry. The people board ranks what you have staked, so unapplied points are invisible rather than taxed — a social cost, not a financial one.
One person can hold at most 15% of an item (above a floor of 100, or the first backer of a new item would be capped at zero). The board measures how many people want something, not who spent the most.
Your devices
Every browser that came through the door with your invite, and the Macs each one has reached over WebRTC. A Mac appears here once its WebRTC front joins its room with your invite kept in the Mac app. This list only shows what is yours: the passkey on each Mac decides who gets in, and revoking a device there is what cuts it off.
Your Macs (by address)
Every Mac you have attached, remembered in this browser only — nothing here is sent to the site. Each one is an address the Mac app showed you: its Local-network front or its tunnel. Open one and the WebXR client comes from that Mac itself, over its own TLS, and this page is out of the loop.
Quicker: in the Mac app's Connections, Show QR beside the web address and point your phone's camera at it. The client that opens is served by that Mac, and its Remember this Mac link lands it here. A green dot means the Mac answered just now; grey means this browser could not reach it from here, which on a self-signed Local-network address only means you have not accepted its certificate in this browser yet.