Unix composed text streams with pipes. Port42 composes live surfaces.

Where do all the apps go?

Agents can build an app for anything now. A dashboard for this week, a tool for one task, a prototype before lunch. Most of them are web apps, and there are more every day. None of them has anywhere to live.

A port is a surface with a stream.

A web page has a face, but nothing outside it can read or drive it. A Unix program has a pipe and no face. A port has both, and it is the only primitive Port42 has. It can be HTML, a native terminal, or a browser, and the contract is the same for all three.

Every primitive, the method behind it, and what it makes: the elements of software →

Everything is a port.

The desktop is port 0. A space is a port that holds ports. A terminal, a chart, and a browser tab are ports. Every one of them, at every scope, carries its own chat. One model all the way down, so a grant, an address, or a subscription works the same whether it points at one tile or a whole space.

Address a port the way the network addresses a host.

A mainframe, an intranet host, an internet host. You send to a name, the network resolves it, and the data arrives at a port on that machine. Port42 takes the same idea to the screen. Every surface gets an address, and data goes straight to it, with no copy and paste in between.

You already rely on this every time you text someone. Nobody streams a video of their chat window to you. Both phones hold the same small message and each draws it natively. Streaming pixels is what you do to a surface you do not own. A port is a surface both ends own.

A write is three nouns: an address, an actor, and a token.

Every write to every port, from any surface, carries all three. Port X, by Y, composed against state Z. That is the whole contract, on your computer and across machines. Each noun has one definition, so the protocol means the same thing on the second machine as on the first.

port42://space/<spaceId>/<portId>
port42://<peerId>/<portId>

you · lead (claude code) · ci-bot · machine "tide"

{"token":"51222e11:43"}  →  stale_write, current :44

The messages.

The transport changes. The contract does not.

On your computer, calls go over HTTP and events over a WebSocket, on the loopback door. Between machines, the same envelopes travel end to end encrypted (Noise IK) through a relay that forwards bytes it cannot read. The transport is a seam, so a direct connection can replace the relay later without changing a single message.

Open and documented: MIT licensed, with the reference generated from the live registry. Read the reference · GitHub

Many drivers, one port.

You through the interface, Claude Code, Codex, or any other AI companion in its terminal, the Port42 CLI, another machine over the wire. Every caller reaches a port through the same door, with the same methods and the same permissions. Your click is a write, the same as a companion's call.

Each write carries the token of the state it was made against. If the port has moved on, the write is refused and told the current token, and one retry lands on top of the newer state. That is how a room of companions and a person share one port without overwriting each other. Try it below.

The contract, in one curl.

Any process on your computer talks to Port42 the same way. Here is a port being made, written to, refused on a stale write, and retried.

# who you are: a named client from Settings > Access, with its own token file
AUTH="Authorization: Bearer $(cat "$PORT42_TOKEN_FILE")"

# replies are shown unwrapped: over HTTP each arrives as {"content": "<the reply as a JSON string>"}; the port42 command unwraps it

# make a port
curl -s localhost:4242/call -H "$AUTH" -d '{"method":"port.create",
  "args":{"type":"web","html":"<title>glow</title><h1>0.60</h1>"}}'
→ {"id":"8E00…","token":"51222e11:2","title":"glow"}

# write with the token you hold
curl -s localhost:4242/call -H "$AUTH" -d '{"method":"port.update",
  "args":{"id":"8E00…","html":"<h1>0.30</h1>","token":"51222e11:2"}}'
→ {"ok":true,"token":"51222e11:3"}

# someone else wrote first: yours is refused, and told what is current
→ {"code":"stale_write","error":"This port has changed since you read it. Re-read it and retry.",
    "expected":"51222e11:3","current":"51222e11:4"}

# read the change, then retry once on the current token
curl -s localhost:4242/call -H "$AUTH" -d '{"method":"port.update",
  "args":{"id":"8E00…","html":"<h1>0.35</h1>","token":"51222e11:4"}}'
→ {"ok":true,"token":"51222e11:5"}

Companions learn the door from skills.

Port42 runs no model. What it gives your companions is knowledge. A companion starts with a short brief (who it is, how replies and @mentions work) and loads the rest as skills when the task calls for it. The same five skills load in Claude Code and Codex.

Skills load per session in every Port42 terminal and are never written into your own setup. The brief a companion carries on every turn is 1,298 characters. For a Claude Code or Codex session Port42 did not start, port42 skills install adds them.

Ports feed ports.

A port can publish events, and any other port can subscribe to them. Produce, transform, render, each one a port with its own face, with no code outside the three. A companion can watch a port too, and wake for a turn when it changes.

See and undo what happened.

What Port42 gives you to keep a room full of companions in hand.

One invite, one port.

Share a web port from its Share box and the same port is live on both machines. The link lets in two machines (say their browser, then their Port42) and is then used up. It enrolls each by its key as a named caller with a grant on that one port, and they drive it through the same door, with the same token rules, seeing nothing else you have. Their tile is a window onto your port. What the port is (its content, pushes, and chat) lives on your computer, and what their window shows stays on theirs.

The port has one chat, on your computer, and every call from their machine says who there made it, so the driver chip names their person or companion. With remote wake on (the default on both sides), a mention in that chat wakes the companion it names on either machine, and its reply comes back to the one chat.

Not yet audited. Sharing is new in v1 and has not had an independent security audit. It is encrypted end to end, but until it is audited, don't share ports that hold passwords, customer data, or anything regulated.

A remote caller may call port methods only, only on the ports it was granted, within its rights (see, use, edit, wake agents, fork). Anything else is refused with not_granted. How the two machines reach each other is the next section.

Only web ports can be shared. A shared terminal would take their typing into your shell, and a browser port is signed in as you. Fork makes an independent copy (of someone else's port only when they allowed it), and move hands a port to another machine once and closes it here. You stay in control. Stop sharing any time, and they lose that one port and nothing else.

End to end, through a relay that cannot read.

Both machines only ever connect outward. Each Port42's gateway opens a WebSocket on port 443 to a relay, relay1.port42.ai by default. Inside it, the two machines run a Noise IK session end to end, keyed by each machine's own Ed25519 key. The relay pairs the two keys and forwards ciphertext it cannot read or forge.

Security status. Sharing in Port42 v1 (invites, the relay, and the browser guest) is new code and has not been independently audited. Connections between machines are encrypted end to end with the Noise protocol, the relay forwards bytes it cannot read, and a guest reaches only the port you invited them to. Those are design properties, not audited guarantees. Until an audit is done, treat a shared port like a screen share: don't share credentials, personal or customer data, or anything covered by regulation. Running your own relay keeps sharing traffic inside your network; it does not replace an audit.