[williamloo-scale]

A website env can record every packet its websites' server and frontend containers send and receive, as PCAP, and serve the files through its card. This is opt-in.

• Turning it on: deploy_env takes capture_traffic, and agent-env env deploy takes --capture-traffic. It works for a website env, or a multi env with a website, on a VM. Any other env, and container mode, refuse it.

• Capture: each website container gets a tcpdump service beside it.

  • tcpdump comes from the gateway image and runs in that container's network namespace (network_mode: "service:<container>").
  • It's the only service holding NET_RAW/NET_ADMIN.
  • It writes rotating classic pcap files, 10 of 20 MB each with the oldest overwritten, to a volume no website container mounts. The gateway mounts it read-only.
  • The deploy is refused if a capture isn't running once the gateway is up.

• Protocol: the new agentenv_protocol.traffic defines urn:agentenv:traffic/v1 with two ops:

  • list returns a TrafficCaptureListing, oldest file first;
  • get streams one file as application/vnd.tcpdump.pcap.

  Client helpers: list_traffic_captures, fetch_traffic_capture, serves_traffic. The gateway's constants.py mirrors the names, with a test keeping them equal.

• Access: both ops require the per-deploy control token (DeployedEnv.control_token). The gateway removes Authorization from a proxied request only when it carries that token (compared with hmac.compare_digest), so no site can read the token, and a site's own bearer auth still reaches it.

• Collection: the new collect_traffic_capture step stores each capture as a pcap FileArtifact in one FileArtifactUniverse, recorded under context.metadata["traffic_captures"][env_id]. It's best effort unless fail_task_on_error is set. Teardown also collects any capturing env the run didn't collect, before the env closes, so a capture isn't lost with its VM.

Before merging

• Not yet run on a deployed VM. The compose wiring, gateway routes, token stripping, step and teardown are covered by unit tests.

Test

Rebased onto main after #444, #508, #510 and #514. Unit tests over packages/agentenv-protocol and tst/unit/{env,providers,task_step,task,cli}: 8,207 passed; the two failures, in test_disk_recipe.py, fail on main on the local machine too. Lint clean.

🤖 Generated with Claude Code

Confidence Score: 5/5

No new blocking finding was established; this does not clear the earlier unnumbered threads.

Summary

Adds opt-in website packet capture, token-protected traffic/v1 downloads, and artifact collection before teardown.

• Website deployments can record packets when the deployer opts in.
• The gateway lists and streams packet captures through traffic/v1.
• Task runs save packet captures as artifacts, including during teardown.

Diagram

%%{init: {'theme': 'neutral'}}%%
flowchart LR
  Website[Website container] --> Capture[tcpdump sidecar]
  Capture --> Volume[Rotating capture files]
  Volume --> Gateway[Gateway reads files]
  Client[Collector with control token] --> Gateway
  Gateway --> Artifacts[File artifacts and universe]
  Artifacts --> Run[Saved run reference]

Loading

_{Reviews (12) · Last reviewed commit: "docs(website): traffic capture records w..." · Reviewed by Greptile}

[earakely-scale]

🤖 Automated Claude routine — Env Pod PR Context Review. This is a bot, not Edgar Arakelyan; not a human review.

Context from outside this diff: #492 ("fix(env): the gateway's control routes take the deploy's control token") is also open against main and builds the same AGENTENV_CONTROL_TOKEN mechanism in the same three files. Neither description mentions the other, so neither CI run sees the pair.

Both add CONTROL_TOKEN_ENV = "AGENTENV_CONTROL_TOKEN" to env/gateway/constants.py (here at :157, in #492 at :71), both add control_token to DeployedGateway (env_gateway_provider.py:142 here, :134 there), and both set self._control_bearer = f"Bearer {control_token}".encode() in Gateway.__init__ (gateway.py:186 here, :169 there). Those read as ordinary conflicts. The one that doesn't is the pair of wrapper steps:

• Here (gateway.py:504-505, head 01650f0): the first thing app() does is scope = self._take_control_token(scope), which removes the Authorization header when it matches the bearer — before the scope["type"] != "http" early return. Each framework-only route then asks _refuse_uncontrolled (:530), which reads the agentenv.control scope key the strip left behind.
• In fix(env): the gateway's control routes take the deploy's control token #492 (gateway.py:480, head eda2a8c): the gate sits after that early return and reads the header back out of the scope — dict(scope.get("headers", ())).get(b"authorization", b"") compared against self._control_bearer — 401ing any path in CONTROL_ROUTES (constants.py:165: the /tools/*, /triggers/*, /clock/* and /notifications/* routes).

On the natural keep-both merge the strip lands first, so by the time #492's gate looks the header is gone and compare_digest(b"", bearer) fails. That would 401 every call to those eleven routes on a token-bearing gateway — including the framework's own, which do send it: Env.control_headers → agentenv_protocol/client.py:47-49 emits exactly Authorization: Bearer <token>, and task/task.py:654 grants it for every deployed env. Worth agreeing up front which PR owns the wrapper gate rather than resolving it at merge time, since both orderings look right in isolation.

Two smaller divergences in the same pair, if they're settled together:

• When a token exists at all. env_gateway_provider.py:759 here draws one only for a capturing deploy ({"control_token": secrets.token_urlsafe(32)} if capture_traffic else {}); fix(env): the gateway's control routes take the deploy's control token #492's deploy() draws one on every deploy (:646, control_token=new_control_token()). So whether traffic/v1 is reachable without a token depends on which is in force.
• Two refusal bodies for one condition. error is an object here ({"code": "unauthorized", "message": ...}, gateway.py:535-536) and a plain string in fix(env): the gateway's control routes take the deploy's control token #492 ("this route takes the env's control token"). A client reading error would see both shapes on one gateway.

Not a review of this diff — only that the two halves are in flight at once and the merge order decides the behaviour.

---

Generated by Claude Code