[williamloo-scale]

The computer side of this change; its gateway side landed first as #505. Rebased onto main without #444–#447.

A deployed computer reaches the run's websites by their own names (https://notes.test/), opt-in.

• Boot order with site_routing: the boot waits only for the driver to answer, then the sites are routed, the held boot apps launched, the computer readied and its display checked, so a browser computer, whose page driver's screen is its browser's page, boots too; a reset does the same.
• Name table (computer/utils/sites.py): each site's names claimed once, a site's names over the network allowlist. Live sites are left out until they land (FD-4945).
• Per-deploy CA, name-constrained to those names, signs a certificate for each site.
• site_proxy.py, standard library only, runs on the computer's python3: it maps the names to loopback, trusts the CA (system store, Firefox policy, NSS) and proxies 443/80 (and DNS for wildcards) to the site's gateway route with X-Forwarded-Host/-Proto and AgentEnv-Site-Root (feat(gateway): WebSockets on a site's route, a site served at a front's own root, and the provider's headers kept from sites (FD-4683) #505), rewriting redirects and cookies and relaying WebSockets.
• env_params.site_routing (true, or env ids): deploy_env fills the table from the websites deployed before the computer, read from their cards; once the computer is ready the provider installs the proxy and records the table, the CA and each name's check. A reset routes the new computer under a new CA. Without site_routing nothing changes.

Before merging

• Fits main's WebsiteBrowserEnvironment (feat(computer): WebsiteBrowserEnvironment, the base class for website browsers #449): this proxy answers on loopback through the hosts file, so a website browser in a computer, which bypasses loopback and has no AGENTENV_SITE_PROXY set there yet, reaches the sites through it. Setting AGENTENV_SITE_PROXY in a computer (M5.5/M5.7) would need a forward proxy, which this isn't.
• Linux computers only. The proxy has been checked from a Mac against the real Notes site over HTTPS, but not yet inside a deployed Linux computer.

Test

• CI on this head. Locally: env, task-step and provider units 6,113 passed (two macOS-only disk-launcher tests fail on main too); protocol 1,219 passed; lint clean.
• End to end on a VM (local Docker, an SDK site at slack.e2e448.test behind a gateway), inside two deployed Linux computers with site_routing:
  • Desktop (ubuntu-24.04, the reference driver, Chromium): the name resolves to loopback; a page, base_url (https://slack.e2e448.test, no prefix), a trailing-slash redirect (307 onto the name), a session cookie (Path=/, no domain), a WebSocket (101 and an echo), port 80 (308 to https) and 50 requests at once all answer through the proxy over TLS the system trusts; the site's data plane and card are 404; Chromium opens the site by its name. The proxy killed is back within 20 s; a gateway restart, a site restart and a paused gateway recover; a reset routes the fresh computer under a new CA, Chromium and the WebSocket working again.
  • A browser computer (agentenv's Chromium alone, its page driver's screen its browser's page): it deploys in 5 s and opens the site by its name, before and after a reset. The run found the two boot fixes here: the boot waited for a ready computer whose browser's launch it held, and the held browser was looked up by the computer's own name.

🤖 Generated with Claude Code

Confidence Score: 5/5

The changes appear safe to merge; the shared boot path preserves the required order.

Summary

Adds opt-in website routing inside Linux computers, including local names, trusted certificates, and an HTTP/WebSocket proxy.

• Opted-in computers reach earlier websites by their declared names.
• Browser computers launch their boot apps after site routing is ready.

Diagram

%%{init: {'theme': 'neutral'}}%%
flowchart LR
  A[Driver answers] --> B{Site routing enabled?}
  B -->|Yes| C[Install names, certificates, and proxy]
  C --> D[Launch held apps]
  D --> E[Wait for computer readiness]
  E --> F[Check display]
  B -->|No: already ready| F
  F --> G[Return deployment or finish reset]

Loading

_{Reviews (28) · Last reviewed commit: "refactor(computer): one sequence for wha..." · Reviewed by Greptile}

[earakely-scale]

We've reviewed this against our plan for websites in the computer. Three parts are better than what we'd planned, and we've changed our design docs to follow them:

• the CA made for each deploy, limited to the run's site names, with its key discarded after signing;
• the transparent loopback routing;
• the site table's rules.

The latest commits already fix three things we'd found: Chromium's trust (the CACertificates policy), the check's time budget, and WebSockets through the gateway. Four things are inline. Three smaller ones are below, and are optional.

Smaller things:

• Leaf keys: RootChannel.write (sites.py:324) sends them base64-encoded in a bash -c argument, through a staging file in the VM host's /tmp. write_secret_file avoids both.
• site_routing validation: run_env_params (computer/env.py:172) uses the value before ComputerParams validates it. "web-env" becomes one env id per character, and 1 raises a TypeError.
• Rewrites:
  • a scheme-relative Location: //gw/website/notes/x is passed through unchanged (site_proxy.py:181), so the browser leaves the site's name for the gateway;
  • Set-Cookie: ...; Path = /website/notes/x, with spaces around =, isn't rewritten (site_proxy.py:200).

[williamloo-scale]

@earakely-scale thanks for the review. Everything you raised is now addressed in #448:

Inline (replied to and resolved on each thread):

• Boot apps vs routing (55c29836): with site_routing, the boot environment holds each app's boot launch. Readiness counts a held app as ready. Once the sites are routed, the provider launches the held apps through computer-app/v1 launch, a framework-only call, then waits until the computer is ready. Chromium's start URLs and Firefox's policies therefore see the hosts entries, the CA and the proxy already in place. A reset does the same.
• Proxy as the session user (55c29836): serve drops to nobody where the base has it, else to the session user. A root keep loop restarts it. Its log is root-owned beside the config, opened O_NOFOLLOW with mode 0600, so a planted link is refused.
• OPTIONS on website routes (55c29836): both /website/<name> routes accept OPTIONS, so a cross-name CORS preflight reaches the site.
• _ in a site's name: already handled. fallback_name maps _ to - before .localhost, so slack_website gets slack-website.localhost.

The smaller three (faf8e7c2):

• Leaf keys: the routing config holds each site's leaf key and the provider's upstream headers. It now goes through RootChannel.write_secret, which writes with write_secret_file over the exec's stdin into a staging folder only its owner can open. It is then docker cp'd into the container's root-only /etc/agentenv/sites, and the staged copy is removed. It never appears on a command line or in a shared /tmp path. Tested by test_the_config_holding_the_keys_is_written_over_stdin_into_a_private_staging_folder_never_as_text.

• site_routing validation: run_env_params refuses anything other than true or a list of env-id strings before using it, so "web-env", 1 and ["web-env", 2] each raise a clear ValueError. Tested by test_a_site_routing_that_is_neither_true_nor_a_list_of_env_ids_is_refused_before_it_is_read.

• Rewrites:

  • a scheme-relative Location: //gw/website/notes/x is read with the page's scheme and moved onto the site's name, while //other.example/... is left alone;
  • Set-Cookie: ...; Path = /website/notes/x is rewritten whatever the spacing around = or the case of path.

  Covered by test_only_a_location_on_the_sites_route_is_moved_onto_its_name and test_a_cookie_path_on_the_route_is_rooted_however_it_is_spelled.

Each new test fails on the code before its fix.

[greptile-apps]

Comments Outside Diff

These findings could not be posted inline.

•  Failed checks leave sites empty packages/agentenv-protocol/src/agentenv_protocol/website/conformance.py:191 ▶

  _data_plane() marks the exported data as restored before calling data/add. If that request fails before writing anything-for example, on a temporary server error-the earlier data/reset has already cleared the site, and the finally block skips its recovery attempt.

  Mark restoration complete only after it succeeds, and preserve the export if recovery also fails.

•  Saved website state gets skipped src/agent_env/env/legacy_protocol.py:89 ▶

  backing_servers() uses the card's display name as environment_name, although loading expects the name in the environment definition. For a service named notes whose card says Notes, it exports state under Notes and adds a second, cardless notes entry. That entry is skipped, while MultiEnv.load_environment_artifact() cannot match Notes and skips the saved state on reload.

  Match listed children to their service routes and keep the definition's name for snapshot artifacts.