# Surviving DOM churn: BrowserAct's state index vs raw Playwright

> Source: <https://promptcube3.com/en/threads/4578/>
> Published: 2026-07-31 19:56:36+00:00

# Surviving DOM churn: BrowserAct's state index vs raw Playwright

[Claude Code](/en/tags/claude%20code/)browser tasks die on the second run. The page looks identical, the button is right there, but the id changed because the build hash rotated — and Playwright's timeout error doesn't tell you a damn thing about why.

Full disclosure before the tech: BrowserAct sponsored this test, and the links in the original post were affiliate-tracked. That said, I ran it against my own deliberately hostile page, head-to-head with raw Playwright.

Here's the shape of the failure. A frontend re-renders with fresh CSS-module or styled-components hashes on every deploy. You write:

``` js
const id = await page.locator("button").getAttribute("id");
await page.reload();
await page.locator(`#${id}`).click({ timeout: 3000 });
```

Works the day you write it. Breaks the next time the build hash changes, and the failure is a bare timeout:

```
locator.click: Timeout 3000ms exceeded.
```

Playwright's own role/text locators fix this specific case — `getByRole("button", { name: "Submit" })`

survives id/class churn fine, because it never depended on the hash in the first place. That's a real fix, not a workaround. What it doesn't give you is a representation of the page an agent can reason about turn by turn, or a signal that says "the page under you just changed, stop and re-check." That's the gap BrowserAct is actually filling.

The interaction model is different. BrowserAct doesn't hand [Claude](/en/tags/claude/) Code a selector at all. The loop is: read the current state, choose an action from what's actually there, execute it, reassess.

``` plaintext

state -> indexed list of interactive elements, as of right

[Next Why We Deprecated These AI Agent Skills →](/en/threads/4562/)