[williamloo-scale]

Stacked on #446.

Live and replayed websites, on main's website SDK and browser/v1 (no website.toml: a site's env.toml declares it, and its card says it is live).

• Live sites. @website(domains=[...], live=True, allow_hosts=[...]) declares a real site: its server serves only the data plane and the card (which advertises live, allow_hosts and signs_in, and whose ready says whether its account works). @session returns the storage state a browser adds to start signed in, in browser/v1's cookies/set and local_storage/set shapes, a cookie without a url or domain given the site's first domain; self.setting(name) reads a credential the deploy passes. A synthetic site may override its signed session cookie the same way. A computer's site routing never routes a live site, which the browser reaches at its real domains.
• sign_in_browser step. Calls each live site's website/v1 session and hands it to a browser child that serves browser/v1 cookies/set (main's WebsiteBrowserEnvironment does): the site's old cookies go through cookies/delete when served, then cookies/set, then local_storage/set (refused on a browser without it); with two browsers, browser must name one. reset_env signs in again. A deploy with a live site is marked reproducible=False with its live_websites, checked against the computer's allowlist. Records and errors never repeat a value.
• Playwright MCP browser serves browser/v1 cookies/set and cookies/delete in the website browser's shapes, writing its storage state file and, through DevTools, any running context.
• Website env settings. A website env's settings (env.toml or stored) are its container's environment variables. A secret-looking setting must be a secret:/env: reference, resolved only into the compose file, which is logged masked. The gateway's own variables can't be set.
• Replay. python -m agentenv_protocol.website.replay capture URL... writes WARC 1.1; ReplayWebsite serves a capture for any host, with @api routes taking precedence, whose state the subclass keeps itself (add_site_data, reset_site_data, its own @get_data); a data/add WARC part replaces the capture until data/reset. Example in examples/website/replay/.

Before merging

• The Playwright MCP recorder's protocol floor rises to 0.1.467, the first release with the website browser's cookie shapes, which it imports.
• website.session is now the decorator, which shadows the module.
• The replay example's Dockerfile installs this repo's protocol from the repo root, so its env.toml can't be built as a bundle folder until a protocol release has website.replay.
• No run against a real browser or a real live site yet.

Test

CLI, config, bundle, env, task, task step, env provider and protocol suites: 8,110 passed. Two test_disk_recipe tests fail and the rubrics non-finite-scores module can't import hypothesis, as on main on this machine.

🤖 Generated with Claude Code

Confidence Score: 4/5

Fix the live-only computer deployment failure before merging.

Findings

1.  Live-only runs cannot start ▶

Fix with agent prompt

### Issue 1
src/agent_env/env/envs/computer/utils/sites.py:447-449
When a run deploys only live websites, this filter makes `deployed_sites()` return an empty list. `ComputerEnv.run_env_params()` treats that as no websites having been deployed and raises, so a computer using `site_routing=True` cannot deploy.

Allow a live-only result to proceed without synthetic routes, while still rejecting runs that deployed no websites.

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

Summary

The latest changes keep live websites out of synthetic routing and move WARC parsing into a worker thread.

• Live website environments can share real sites with a run.
• Sign-in steps put a live site's session into its browser.
• Captured websites can be replayed with their API routes on top.

_{Reviews (21) · Last reviewed commit: "fix(website): a computer never routes a ..." · Reviewed by Greptile}

[earakely-scale]

Website settings: suggest following the computer-app model

This PR makes a website env's settings bare environment variables of its container: self.setting(name) reads one, a setting whose name looks like a secret's must be a secret: / env: reference, and RESERVED_SETTINGS keeps them off the provider's own variables.

Computer apps already have a settings model for the same job (agentenv_protocol/computer/app.py):

• the class declares class Settings(BaseModel), and a SecretStr field is a secret;
• its JSON schema is stored with the env (AppDeclaration.settings), and put checks values against it;
• the server receives every value in one JSON variable keyed by environment_name (AGENTENV_APP_SETTINGS), validated into self.settings as it starts.

Suggest websites do the same, implemented in the website package (no imports from computer/):

• WebsiteEnvironment.Settings, read as self.settings, so a live site's credentials are SecretStr fields rather than names that look secret;
• values validated as the server starts, so a bad or missing value fails the deploy with the validation error, as an app's does, and at put too wherever the schema is known;
• one JSON variable, so settings can't collide with the provider's own variables (DATABASE_URL, WEBSITE_ROLE_KEY, and now WEBSITE_SESSION_SECRET from feat(website)!: WebsiteEnvironment serves a site on the website/v1 contract, and a conformance check tests any server (FD-4683) #428), and RESERVED_SETTINGS isn't needed.

For the rebase: #428 now validates @website(domains=...) with host_problem (moved down from this PR), drops health= in favour of ready with @website(ready_timeout_s=...), and answers session with {cookies, local_storage}, each cookie with max_age (see the resolved thread on #428).

[greptile-apps]

Live-only runs cannot start

When a run deploys only live websites, this filter makes deployed_sites() return an empty list. ComputerEnv.run_env_params() treats that as no websites having been deployed and raises, so a computer using site_routing=True cannot deploy.

Allow a live-only result to proceed without synthetic routes, while still rejecting runs that deployed no websites.

Prompt To Fix With AI

This is a comment left during a code review.
Path: src/agent_env/env/envs/computer/utils/sites.py
Line: 447-449

Comment:
**Live-only runs cannot start**

When a run deploys only live websites, this filter makes `deployed_sites()` return an empty list. `ComputerEnv.run_env_params()` treats that as no websites having been deployed and raises, so a computer using `site_routing=True` cannot deploy.

Allow a live-only result to proceed without synthetic routes, while still rejecting runs that deployed no websites.

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

[earakely-scale]

Closing this PR. We're taking over the website stack, and this branch was written against main as it stood on Nov 3. Each part is now superseded, or planned elsewhere:

• Sign-in is superseded by feat(browser): browser_sign_in, and browser steps reach a multi env's computers (FD-4944) #556 (merged): browser_sign_in asks the site's website/v1 session and loads the result into the browser with one data/add. We decided that the task runs the step again after reset_env, so reset_env doesn't sign in by itself. That's decision 1 of the M5.15 design note.
• browser/v1 is on main in agentenv_protocol.website_browser, with cookies/get, cookies/set, cookies/delete and data/add. This PR's agentenv_protocol.website.browser defines a second module under the same URN, so the two can't coexist.
• The spec: this PR is stacked on feat(website): the browser client, env website new and env website dev (FD-4683) #446, which carries feat(website): one spec declares a site, composes it and checks any server (FD-4683) #445's website spec. feat(website): one spec declares a site, composes it and checks any server (FD-4683) #445 was closed on Nov 6 in favour of env.toml (FD-4931).
• Live sites (live, allow_hosts, secret settings, marking a run not reproducible, the network allowlist check) are planned as M5.16, FD-4945. This branch is linked there as prior work.
• Signing in the Playwright MCP website browser (the recorder's cookie methods and its storage-state file) is planned as M8.14, FD-4961, and linked there too.
• WARC replay isn't planned for now. The pywb-based WARC multi env (FD-1046, FD-1047) already covers replayed corpora.

The branch stays for reference, at head 46566a5.