[earakely-scale]

The gateway side of a computer reaching the run's websites by their own names (https://notes.test/), lifted out of #448 so it lands on main first. #448 keeps the computer side (the name table, the per-deploy CA and the site proxy) and is rebased onto this.

• WebSockets on a site's route. A WebSocket to /website/<name>/ is relayed to the site under the HTTP route's rules: refused at the paths the site's card reserves (its data plane and card), with the role and forwarded address the gateway writes, each message and either side's close relayed, a refused handshake's answer passed on, and a message over uvicorn's size closing both with 1009. Adds websockets>=13 to the gateway.
• A front that serves a site at its own root. A client that sends AgentEnv-Site-Root, as a computer's site proxy will, is told no X-Forwarded-Prefix, so the site's links are rooted at / where the browser sees it. Its own X-Forwarded-Host and -Proto still win, as from any front.
• The provider's headers kept from sites. The headers the sandbox provider in front of the gateway is sent (its credentials, sandbox_request_header_names()) reach the gateway as AGENTENV_PROVIDER_REQUEST_HEADERS and are taken off every request it forwards, HTTP and WebSocket.
• browse_url on website/v1. WEBSITE_BROWSE_URL_PARAM: where a composer serves a site to a browser, a path joined onto the composed card's address or a full URL. The provider reads the env card again once the sites are ready, so the card names them.

Held back from #448: its role-key handling, as in #443.

Test

• Unit: gateway and providers 2,823 passed; protocol 1,218 passed; lint clean; uv lock --check clean.
• End to end: with the computer side, on a VM.

🤖 Generated with Claude Code

Confidence Score: 5/5

The PR appears safe to merge; no new blocking issues were found.

Summary

The PR adds website WebSocket forwarding, root-address support, provider-header stripping, and website browse addresses.

• Named website routes now carry WebSocket connections to their site servers.
• Gateway forwarding keeps provider credentials out and lets sites use the front’s root.
• Website cards now point browsers to each site’s gateway route.

Diagram

sequenceDiagram
    participant Client
    participant Gateway
    participant Site
    Client->>Gateway: Website HTTP or WebSocket request
    Gateway->>Gateway: Check reserved paths and remove provider headers
    Gateway->>Site: Forward with role and public address
    Site-->>Gateway: Response or WebSocket messages
    Gateway-->>Client: Relay response, messages, and close

Loading

_{Reviews (3) · Last reviewed commit: "refactor(gateway): one rule for the head..." · Reviewed by Greptile}