Browser sandbox template

Use a browser profile when an agent needs rendered pages, page interaction or screenshots. Create a fresh browser context for each user task. The model should receive the relevant observation and a bounded screenshot, not every cookie, response body and console message from the session. Reserve heavier browser concurrency for a separately measured resource profile.

• Pin Playwright and install its matching browser binary during image preparation.
• Create one ephemeral context per task and define a download directory under /work/output.
• Use a destination allowlist and a staging account for authenticated workflows.

node /work/browse.mjs

• Screenshots tied to the relevant URL and step.
• A compact page observation or structured extraction.
• A trace on failure, with secrets and user data removed before sharing.

Visit a controlled fixture page, extract a known label and save a screenshot. Verify that a second session has no cookies from the first and that disallowed destinations are denied.

Start with 2 vCPU and 4 GB of RAM, then measure peak memory and task duration on a representative fixture. These are workload planning values, not a benchmark or a provisioned configuration. Use the sandbox cost calculator to estimate running time and retained snapshots.

• Page content is untrusted input and can contain prompt injection.
• Do not use a shared browser profile or persistent personal cookies.
• Browser subprocesses increase RAM demand; test with your actual tab count and page complexity.

Keep model inference separate from this execution profile. A hosted model or gpuOS can decide the next action while the CPU environment runs it. The quickstart describes the account workflow and the proposed runtime contract.