Skip to main content
reticle_navigate moves the connected browser tab to a URL, or reloads it in place with { "reload": true }. Reach for it for a genuine document load: a deep link, a hard refresh, or the first visit. Clicking a link inside a single-page app is a route change, not a navigation, and does not need this tool.
Real response, with the throttled-tab session and warning fields trimmed off:

​
confirmed: true when the page comes back in time

The daemon waits up to timeout_ms (default 5000) for the SDK to re-announce itself. When it does, you are told so, with the sessionId it came back as, and can act immediately without a reticle_session { action: "list" } round trip. This is a real reload response:
Read the second sentence, which is the one that costs people a turn. confirmed: true restores the session, not the evidence: every event, network call and console line captured before the reload went with the old document.

​
confirmed: false is the honest part

A full navigation destroys the document the SDK was living in. Reticle cannot report on the new page from inside the old one, because the old one no longer exists. So it tells you what it actually knows: the navigation was dispatched. Most tools would return ok: true and let you assume arrival. When the page then fails to load, or loads without instrumentation, you get a confusing cascade of “element not found” errors several calls later, with nothing pointing at the real cause. confirmed: false with a landedOn URL is a different case: the page arrived, but the app sent it somewhere else, such as a login or route-guard redirect. landedOn says where the browser actually is. waitedMs is how long Reticle waited for the page to come back before it stopped. The page may still arrive after that. A single-page app that reattaches under HMR can take 30–60 s, so give a slow app a larger timeout_ms:

​
The pattern after navigating

then confirm a session reconnected:
with reticle_session, and only then look at the page. If no session appears at the new URL, the page did not load or is not instrumented. And you know that immediately rather than three calls later.
Refs do not survive a navigation. A new document means new refs. Across one afternoon on the same fixture, the same “Sign in” button was e105, then e305, then e3. Re-snapshot; never carry refs across. Reticle refuses a stale ref rather than clicking whatever now occupies the slot, so the failure is loud, but it still costs you a turn.

​
Arguments

​
Client-side routing is different

In a single-page app, clicking a link usually changes the route without destroying the document. That is a route change, not a navigation. Refs survive, and you can assert it directly:
That is a verified call. Its verdict quotes the transition itself:
Use reticle_navigate for a genuine document load. A deep link, a hard reload, or the first visit.
Last modified on October 25, 2026