Puppeteer alternatives for AI agents: when to keep your script or migrate

Keep a Puppeteer script when its steps and completion check still work. Let an agent call that script if it only needs to choose an approved job; consider Playwright when its test runner or browser coverage solves a specific problem. For changing page paths that need human inspection, test ego (lite) as a visible browser route. Whatever you choose, verify the stored result after a page says Saved.

We tested that decision on our own Request Desk. The same Codex model used Puppeteer, Playwright and ego-browser for one four-field task under clean, first-503 and false-Saved conditions. Six runs committed the correct record. In the three false-Saved runs, the server committed nothing and each agent reported Draft after reloading. Those were correctly detected failures, not completed requests. The browser transcripts and server records are below.

The ego-browser runs make the visible route concrete. R03 stored one Submitted request, R06 recovered from an injected HTTP 503, and R09 caught a false Saved message on a fresh read and separate server check. These individual cases show how to inspect an authorized local task; they do not rank reliability or speed. The ego (lite) evidence and original images below show when this route helps.

When should you keep Puppeteer?

Start with the existing job's inputs, the pages it is authorized to open, and the record that proves completion. If those are stable, Puppeteer remains a reasonable executor. You can expose a constrained function such as “submit an approved request” to an agent without asking the model to rediscover every selector. The model chooses the permitted job and inputs; the reviewed script handles the repeatable browser steps and returns a server-verified result. That is an architecture decision, not a new Puppeteer benchmark from this trial.

A separate read-only check with three browser routes

The following public-site screenshots are a separate September 30, 2026 demonstration, outside both Request Desk cohorts. Puppeteer and Playwright each opened MDN's AbortController overview, followed its abort() method link, and read the method page. The Codex controller lists distinct run IDs and reports a reload for each route. Both runs were headed and read-only. Matching answers to this documentation question do not show which library is faster or more reliable, and they do not verify a stored business record.

Do not migrate because an older comparison calls Puppeteer Chromium-only or says it has no automatic waits. Puppeteer's supported-browsers page for v25.12.0 lists Chrome for Testing 154.0.8037.57 and Firefox 156.0.1, with stable Firefox support since v23. Its page-interactions guide recommends Locator actions that wait for relevant conditions. Firefox uses WebDriver BiDi by default and some protocol-specific gaps remain. Our experiment used Puppeteer 24.41.0 over a separately launched Chrome 153, so the current official pairing and Firefox behavior were not part of our run. Puppeteer browser support, Locator behavior, WebDriver BiDi details.

What did we actually test?

The local Request Desk required a synthetic sign-in, an iframe guide, a shadow-DOM assignee, a title, High priority, and the correct one of two Save buttons. Changing priority replaced the submit button. The page also emitted an unrelated console error, a /noise request returning 503, and a missing favicon returning 404. Each agent had to submit, reload, and report the visible server status. The fixture server recorded the private request ledger and final record independently of the agent's account. No real website, personal login, or third-party provider was involved.

We preregistered one clean run, one first-submit 503 run, and one false Saved run for each route. The same Codex CLI 0.155.1 model, gpt-6-sol at medium reasoning, received the same business task; route-specific instructions only described how to control its browser. The formal runs followed R01 through R09 with fresh browser and server state. Earlier failed startup and access pilots remain outside this table and in the evidence bundle. The independent reviewer checked nine server ledgers, agent transcripts, final reports, and all 18 formal screenshots.

The six committed records each had the four target fields: Review shipment 6123, Mira, High, and GUIDE-6123. The three false Saved rows had zero writes. Each agent reported Draft after reload, so the pre-registered fault-handling rubric passed, while business completion stayed false. R02 signed in three times in its clean run, and R08 signed in four times and submitted twice in its false Saved run; both behaviors are visible in the server ledger. The false Saved plan did not cap retries, but those extra actions matter when evaluating an agent's behavior.

We then ran a separately frozen nine-run replication to improve the environment record. It uses the same self-built task and route order, with new run IDs R10–R18, fresh state, a recorded command vector, model configuration, per-run start and end times, and browser version receipts where available. This is a second local cohort, not a replacement for R01–R09 or evidence that 18 trials measure general reliability. The older R08 Playwright false Saved case submitted twice; the new R17 case submitted once. Both ended Draft with zero writes. The original nine-run table and its denominator stay intact.

The replication's three clean runs each had one correct write. Its three first-503 runs each had a 503 response, one retry and one correct write. Its three false Saved runs had no write, and each Agent reported non-completion after a fresh page showed Draft. An independent Agent checked all nine rows, 36 field, status, and write checks, original images and the public package against the server records. That review covers this owned fixture only. The explicit Codex CLI command set model_provider to openai; the JSONL does not independently attest provider identity. Puppeteer and Playwright used host Chrome through CDP, while ego-browser used its bundled Chromium with native app access, so cross-route speed, cost and security remain unmeasured. Download the separate replication evidence.

What did the clean task show?

In R01 the Puppeteer-controlled agent read the guide from the iframe, filled the form, chose Mira inside the shadow DOM, and used the submit Save button. The first screenshot shows the four requested values just before submission. The second, taken after a reload, shows Submitted. The visual status and the server record agree; the assignee button itself has no clear selected style in the screenshot, so the Mira field is verified from the browser action and committed server payload rather than inferred from button color. R02 and R03 produced the same four-field committed record through Playwright and ego-browser, respectively.

What happened after the first 503?

The fault was on /submit, not on the page's deliberately noisy /noise request. In R04, R05, and R06 the first submission returned HTTP 503 and wrote nothing; a single retry returned 200 and committed one correct record. After reload each agent reported Submitted. The server events contain both responses and the final record, so a transient Toast alone was not treated as success. The unrelated console error, /noise 503, and favicon 404 were present to test whether the agent would retry the wrong thing.

A migration should preserve this distinction. Retry a failed write only with an explicit bound and an idempotency rule appropriate to your system. The fixture allowed one retry, and its private ledger made duplicate writes observable. A real application may need its own transaction ID or server API to resolve an ambiguous response. The browser library does not supply that business guarantee for you.

How did we catch a false Saved message?

For R07 through R09, /submit returned HTTP 200 and the page displayed Saved, but the server intentionally skipped the write. A reload removed the form values and exposed Server status: Draft. All three agents then reported non-completion. Their fault-handling rubric passed because they rejected the false positive. The business task did not succeed in any of these rows. R08 made two submit attempts and logged in four times, while R07 and R09 submitted once; that difference is retained in the raw record.

The earlier manual illustrations did not retain a complete browser command trace. These four figures instead come from new, separately frozen MV04B and MV08B captures. Their original screenshots, complete scripted browser actions, CLI output, per-run metadata, and server truth are available in the manual visual replay evidence. The initial capture script failed before a successful case because its Sign in locator matched two elements; that failure is retained in the package.

This is the check to carry into your existing Puppeteer code: define a server-owned completion signal and read it after the action, preferably after a reload or through an authorized application API. Separate a technical action response, an on-page Toast, and the business record. If the record cannot be verified, return an uncertain or incomplete result to the agent and stop automated follow-up actions.

What changes when you move to Playwright?

Our R02 Playwright run used a frame locator for the guide, a locator through the assignee component's open shadow root, a fresh selector after the priority change, and a reload to read server status. The exact excerpt below comes from its preserved run script. It shows a useful migration seam: page access, selectors, and status verification are explicit. It is a task excerpt, not a complete drop-in program; the full script and output are in the evidence bundle.

result.guideRead = (await page.frameLocator('iframe[name="guide"]').locator('body').innerText()).trim();
await page.locator('assignee-picker').getByRole('button', { name: result.assignee }).click();
await page.locator('button[data-action="submit"]').click();
await page.reload({ waitUntil: 'networkidle' });
result.observedStatus = (await page.locator('#server-state').innerText()).trim();

Playwright's official framework supplies a test runner, assertions, isolation, parallel workers, and Chromium, Firefox, and WebKit projects. Those are reasons to evaluate it if your Puppeteer job is becoming a reviewed test suite or needs browser coverage your current setup lacks. Our formal Playwright route controlled only a provisioned Chrome 153 over CDP; the nine runs did not test those other engines or Playwright Test's runner. Puppeteer also has Locators, so “automatic waiting exists only in Playwright” would be inaccurate. Playwright's current installation and runner guide.

A practical migration keeps the business validator fixed while swapping the browser executor. First preserve a known request and its expected server state. Next run the same request through the new library against a controlled fixture, including a failed write and a false-positive UI message. Finally compare the committed record, retry count, and visible after-reload status, then test the actual browsers and CI environment that motivated the change. The library swap should not quietly change what counts as a completed job.

In the separate MDN demonstration, a second capture from the same Puppeteer and Playwright runs shows the complete method page beside the controller's run IDs and original-file links. It is useful for checking what text was visible. The screenshot itself does not include the commands or prove the reported reload; those would require the linked run bundles.

Where do higher-level browser agents fit?

Puppeteer and Playwright are browser-control libraries; the model in our trial decided what actions to take through them. Stagehand documents model primitives such as act, extract, and observe alongside deterministic page APIs. Browser Use Cloud documents a hosted Agent path and a separate Browser Infrastructure path that your own code can control. These are real architecture options, but we did not have the provider credentials for a same-task Stagehand or Browser Use Cloud run. Their docs are capability sources, not measured results in our table. Stagehand documentation; Browser Use Cloud quick start.

When should a Puppeteer team try ego (lite)?

Try ego (lite) when the page path changes and a person needs to inspect or take over the agent's work in an authorized local browser. Keep Puppeteer for a fixed job that already has a reliable completion check. To compare them, hold the request fields and server-owned success rule steady while changing the executor. ego (lite) is a visible browser environment, not a drop-in test runner or hosted session. ego (lite) quick start.

What the visible MDN route shows

A third read-only documentation run used ego (lite) to move from the MDN AbortController overview to its abort() method page. The Space overview shows one named task Space and one blank Space. It establishes a visible browser workspace, not two parallel tasks or a tool advantage over Puppeteer.

The controller and browser are visible together at the overview's AbortController.abort() link. That makes the navigation target inspectable before the agent opens the method reference.

The next frame shows the method reference in that visible Space. Its visible text says abort() stops an asynchronous operation before completion, and the syntax lists abort(reason). This frame shows the method page during active control; it does not show a post-reload check.

Our formal ego-browser CLI runs used that same four-field Request Desk task. R03 reached one correct Submitted record after one POST 200. R06 received one injected 503, retried once, and then reached one correct record after a POST 200. R09 displayed a misleading Saved response after POST 200, but a fresh page showed Draft; the independent admin state recorded zero writes and the Agent reported the job incomplete. These are one run per condition, so they show how to inspect this local workflow, not a success rate or an advantage over Puppeteer.

Inspect the original R03 screenshot.

Inspect the original R09 screenshot.

To test this choice on your own authorized job, first preserve its input and server-owned completion rule. Run the existing Puppeteer executor and an ego (lite) Space against separate fresh instances of the same task, including a rejected write and a false-success message. Compare the after-reload status, committed record, and retry count before replacing any working script. The versioned original screenshots, run transcripts, and per-run results are in the reproduction pack above; the ego figure source and crop mapping links each new figure to its raw run. We did not test imported logins, two-factor prompts, remote concurrency, or production security boundaries.

How should you test your own migration?

Write down a real authorized job before comparing tools: its input, permitted site and account, expected record, and stop condition. Record the current Puppeteer run first. Include at least one changed element, an ambiguous control, and a failure that can show a success message without a committed result. Capture the action log, before and after screenshots, and a server-owned verification signal. Then change one executor at a time and ask an independent reviewer to score the same fields. If the new route cannot be run with the necessary credentials, mark that route untested instead of filling a comparison cell from a product demo.

1. Keep the existing script when it performs a known job and already has a reliable completion check.
2. Add a bounded agent interface when the model needs to select among approved jobs, while the script remains the executor.
3. Evaluate Playwright when browser coverage, test runner features, or team maintenance costs justify code migration.
4. Evaluate a visible browser agent when the page path is uncertain and authorized human inspection or takeover is part of the task.

FAQ

Is Puppeteer still Chrome-only?

No. Puppeteer's current supported-browsers documentation lists stable Firefox support since v23.0.0. Check the exact package and browser version in your project before assuming a feature works on both engines; protocol-specific differences remain. Our trial ran only Chrome 153 for the Puppeteer route.

Does an AI agent need to replace my Puppeteer script?

No. A reviewed script can remain the executor for a stable workflow. An agent can choose a permitted job and provide validated inputs while the script enforces origins, actions, and completion checks. Use a model-operated browser when those steps cannot be predetermined and the added flexibility is worth the oversight and failure handling.

Why did the false Saved runs count as fault-handling passes?

The server deliberately wrote no record. The agents reloaded, saw Draft, and did not claim submission, which satisfied the pre-registered detection rule. Business completion was false in R07, R08, and R09. Those rows cannot be included in a numerator for completed requests.

Did this test Stagehand or Browser Use Cloud?

No. Their official guides informed the architecture map, but provider access was unavailable for the same local task. This article contains no measured completion, token, cost, or speed result for either service.