you and your agents share the same terminals.
phux makes every terminal a first-class object on a wire. panes are just a view — the terminal underneath is something anything can drive: you, a gui, or an agent.
live, in your browser — the same bytes a gui or an agent gets off the wire. this is a self-destructing sandbox: no network, auto-nukes on disconnect.
the passthrough is the proof
what you just saw render — sixel images, kitty keyboard, osc 8 hyperlinks, true color — is the actual terminal stream, not a screenshot and not a re-render. it is the exact byte sequence a phux client receives off the wire. a browser canvas drew it here; a gui frontend or an agent would consume the very same bytes.
the demo is honest about what it is: a self-destructing jail. it has no network access and it auto-nukes the moment you disconnect. you are driving a real phux terminal, just one that can't outlive the page.
not tmux
tmux re-parses your terminal. it stands between your emulator and your programs, interprets the byte stream itself, and re-emits its own approximation. every protocol it doesn't already understand gets flattened on the way through — which is why graphics, kitty keyboard, and newer escape sequences degrade the moment you attach.
phux never re-parses. the same libghostty vt engine runs on both ends of the wire, so the stream that leaves a program is the stream that reaches you. there is nothing in the middle reinterpreting it — present protocols and future ones pass through by construction, not by feature work. it's a structural property, not a longer feature list.
a terminal is an object on a wire
strip away the panes and what's left is the real model: every terminal is an addressable object you can spawn, observe, and drive over a wire. the multiplexer view you saw is one consumer of that wire — not the thing itself.
spawn
open a terminal as an object with a stable id, independent of who's watching it.
observe
attach to its live byte stream — the same stream any other consumer sees.
drive
write input to it, resize it, move it — from a tui, a gui, or a program.
the wire is layered: l1 carries raw terminal bytes and input; l3 carries metadata and links between terminals. it's a small, legible surface — read the wire spec, or start with the concepts.
the wedge: the wire as product
the tui is the on-ramp. it's how a human gets in: a familiar multiplexer that, unlike tmux, doesn't break the modern terminal. but the tui holds no special status — per adr-0017 it is a pure consumer of the wire, with no privileges a program couldn't also have.
that's the wedge. because the terminal is a wire-addressable object, humans and agents are co-present on the same terminals at the same time — not an agent scraping a human's screen, but both reading and writing the same object. the wire is the product; the panes are how you first touch it. start with the reference tui.
built for agents, honestly
an agent doesn't get a privileged protocol. it gets the same wire you do. structured agent state — a clean, queryable picture of a terminal — is a local projection built on the client side, exposed as a cli and json. it is not a separate gRPC service bolted onto the wire; the wire stays one thing.
the agent sdk is, deliberately, a copy of what the phux-web browser client already does: load the engine, consume l1, project state locally. if the browser can do it, an agent can do it the same way — no second path. see the agents consumer for the shape of it.
this is the direction, stated honestly: the substrate is here, the projection is real, and it's early. it's the reason the wire exists, not a shipped, finished product.