Run

meticulous-cli-update

first if you haven't already this conversation (it also covers authentication and project selection).

1. One or more test runs from newly recorded sessions that provably extend coverage. "Provably" means a comparison against the baseline naming the files whose coverage went up, and by how much (Step 7). If a target turns out not to be coverable, say so rather than padding the list.
2. A PR proposing

   .meticulousignore

   changes. Only include paths — most often whole directories — that you are confident are not coverable at all. Anything you merely failed to reach in one sitting does not belong there; leave it out and mention it in the PR description instead.

• .meticulousignore

  candidates — files that are uniformly at 0% across a whole directory, which suggests they never execute in a browser at all.
• Coverage targets — files a real user flow could reach but no recorded session happens to. These are not only the 0% files. A file at 12% or 40% usually means one path through it runs and the rest doesn't, and those partial files are often the cheapest wins: the module already loads, so a single extra interaction can light up a large block. Sort ascending by percentage and work up from the bottom, rather than stopping at 0%.

packages/<name>/…

undefined

• Claude in Chrome — the only one that drives the user's own signed-in Chrome profile, so an authenticated app needs no login flow. Its input path is also the one that wedges (see below), so verify early and be ready to switch.
• Playwright and

  agent-browser

  — CDP-launched browsers, faster and more scriptable, and reliable in every test here. The trade-off is a fresh profile each time, so you have to sign in.

  agent-browser

  additionally refuses a click when the target is covered by another element, naming the covering node, which catches a class of silent mis-click the other two will happily perform.

element.click()

input.value

window.__ev = [];
["pointerdown", "click", "keydown", "change"].forEach((t) =>
  window.addEventListener(
    t,
    (e) => window.__ev.push({ t, trusted: e.isTrusted }),
    true,
  ),
);

• nothing captured → your input never reached the page; a different selector or coordinate won't help (see the wedged-extension note below)
• captured but

  trusted: false

  → it reached the page but will not be recorded; you are synthesising somewhere

• Screenshots are downscaled (~0.6x), so they are not CSS pixels. Click coordinates read off the screenshot, or scale a

  getBoundingClientRect()

  centre by

  screenshotWidth / window.innerWidth

  . Re-derive after any resize, and re-screenshot rather than reusing coordinates from an earlier page — layout shifts, and a stale coordinate can land on the wrong element and record an interaction you did not intend.
• Re-acquire a

  ref

  immediately before clicking it, and never reuse one across pages or tabs. Don't predict a number —

  read_page

  does not emit them in order. Refs and coordinates are equally reliable; pick whichever is convenient. This is not unique to

  claude-in-chrome

  —

  agent-browser

  's

  snapshot

  refs go stale the same way, and reusing one silently clicks whatever now occupies that ref, not what you intended. It cost a real mistake once: a stale ref landed on a table's "Add New" affordance and created a blank record. Take a fresh snapshot immediately before every click when the DOM might have changed, and treat an unexpected page/record-count change right after a click as a sign a ref just misfired, not as an unrelated bug — clean up whatever it created before continuing.
• Input delivery wedges intermittently. Every click and keystroke reports success, reads keep working, and nothing reaches the page. Refs and coordinates die together, so this is never a selector problem — and it is not cleared by a new tab, a fresh navigation, waiting, or retrying. A full Chrome restart helps but does not durably fix it. Check the probe after your first interaction, before driving a whole flow, and if input isn't landing switch to Playwright or

  agent-browser

  rather than switching selector method. Both stayed reliable throughout, including on the same page at the same moment that Claude in Chrome was dead.

1. Navigate to the target URL and drive the real action.
2. Confirm it worked against the DOM (e.g.

   document.body.innerText.includes(...)

   ), not just a screenshot — a tooltip appearing can look like success. Check you are still on the page you think you are: an app that has quietly redirected you to a login screen will absorb blind coordinate clicks into empty space and hand you a session with zero events.
3. Close the tab.

meticulous agent sessions --limit 10 --excludeSyntheticSessions \
  --includeDurationSeconds --includeNumberUserEvents \
  --includeNumberUrlsVisited --includeStartUrl --includeAbandonedReason

• no row at all — nothing was uploaded yet; wait a little longer before concluding the recording failed

• numberUserEvents

  of 0 — the recorder saw no user input. Your clicks were not reaching the page, or were synthesised rather than trusted; go back to the input-delivery probe above. Replaying this session is pointless.

• numberUrlsVisited

  of 1 when you navigated several times — the later pages did not make it into this session. They either landed in their own sessions (fine, collect those ids too) or were swallowed as an unreplayable tail (see the hard-navigation note in Step 5).

• durationSeconds

  over 300 — everything past the 5-minute mark will be silently trimmed on replay (Step 5). Re-record the overflowing part as its own session rather than hoping it survives.
• populated

  abandonedReason

  — the recorder gave up on the session (see the 10-minute cap in Step 5); it is not worth replaying.

• startUrl

  that is not the page you drove — the navigation you cared about belongs to a different session than you assumed.

numberUserEvents

sessionStorage

• Cloud replays cap at 5 minutes of session time. Everything recorded after that is silently trimmed from the replay — the run still succeeds and reports itself accurate, so the loss is invisible unless you look for it (snapshot routes stop early; far fewer allowed events than the session has clicks). Don't leave this to feel:

  agent sessions --includeDurationSeconds

  gives you the number, and anything over 300 is losing its tail.
• Your interaction pace eats this budget. Each find/click/verify round trip is 10-60s of recorded session time. Plan the flow completely before opening the tab, batch your actions into as few round trips as possible with short waits between them, verify from the recording afterwards rather than mid-flow, and aim to stay under 4 minutes. Several short sessions beat one long sweep.
• Direct URL navigation is a legitimate fast path to each target page and replays fine — prefer it over slow click-paths. But hard navigations split the recording into multiple sessions, so collect every resulting session id afterwards and pass them all to

  --sessionIds

  (Step 6). Mostly this is fine, each piece staying under the replay cap. The trap is navigating again too quickly: a page reached a second or two after the previous one gets appended as the tail of that session instead of starting its own, and tails frequently do not replay — so the page renders perfectly while you drive it and still contributes no coverage. Give each page you actually care about its own dwell time (~10s) before moving on, and check in Step 6 that it shows up as a

  startUrl

  in its own right.
• Recorder limits: a 10-minute hard cap on tab-open time marks the whole session "abandoned"; uploads flush on a 5s interval — wait ~6-8s after the last interaction before closing the tab.