Browser-agent debugging usually starts with a weak sentence: "Can you run it again?" The problem is that the second run is not the first run. Time moved. Network responses changed. The DOM settled in a different order.

Hand-drawn DBAR diagram showing time, network, and state captured into a replay capsule with hashes.
DBAR records the main sources of browser variance and compares strict observables during replay.

I built DBAR, Deterministic Browser Agent Runtime, to make supported Chromium sessions easier to audit. It does three things at the Chrome DevTools Protocol boundary:

  • Virtual time: detach page timers from wall-clock time where Chromium allows it.
  • Network record and replay: capture request and response pairs, then serve recorded responses on replay.
  • State snapshots: store DOM, accessibility tree, screenshot, and hashes at step boundaries.

The output is a replay capsule. It contains the manifest, network transcript, snapshots, and hash chain needed to validate a run later.

capture -> capsule -> replay
strict: DOM hash, accessibility hash, network digest
advisory: screenshot hash

I call screenshots advisory because pixels can vary across machines through fonts, GPU compositing, and antialiasing. DOM, accessibility tree, and network digests are stricter signals for the cases DBAR supports.

The value is not that DBAR makes every browser behavior perfectly deterministic. That would be too strong. The value is that it controls the major sources of variance for a supported run and tells you exactly which recorded observable diverged when replay fails.

That is enough to turn a vague failure into a concrete one:

step 4 diverged
observable: accessibility-tree
expected: a3f2...
actual:   b7c1...

DBAR is independent of BAP. It works with Playwright-based setups and can attach through CDP when the runtime exposes a Chromium connection. The package is public on npm and the repo is public now.

GitHub / npm