Debugging from a screenshot is the worst
You know the scenario. A colleague opens a ticket: "the form doesn't submit." No stack trace, no network tab, no reproduction steps. Just that sentence and maybe a blurry screenshot. You open the app, click around, and everything works fine for you. The bug might as well be a ghost.
The old workflow was to ask for a screen recording, or remote in, or paste a DevTools screenshot into ChatGPT and hope for the best. None of that is fast. None of it gives the AI the raw, structured data it actually needs to reason about the problem.
That's where lac /watch comes in.
What /watch actually does
/watch is a browser monitoring mode built into lac-cli. When you run it, it injects a lightweight observer into your browser session that tracks everything happening on the page in real time:
- Every click, with the element target and coordinates
- Every input change
- Every navigation event
- XHR and
fetchrequests, including headers and request body - JavaScript errors and unhandled promise rejections
All of that gets assembled into a chronological session timeline. And then — this is the part that makes it useful — a floating Send to AI button appears in your browser. One click, and the full timeline goes straight to lac agent.
No copy-pasting. No manually pulling network logs. No describing what happened. The agent gets the actual sequence of events.
Running it
If you have lac-cli installed (pip install lac-cli or the install script at lacai.io/lac-cli), you just run:
lac /watch
It'll prompt you to open or reload a browser tab with the monitoring script active. From there you use the app normally. The observer runs silently in the background, building up the session timeline as you interact.
When something goes wrong — or when you want the agent to analyze what just happened — you hit the floating Send to AI button. Done. The agent picks up the timeline and starts working.
A real example
I used this last week on a small internal tool. There was a payment flow that was silently failing for some users. From the outside, the button just stopped responding. No visible error. No toast. Nothing.
I started a /watch session, reproduced the failure on a staging account, and sent the timeline to lac agent. Within about thirty seconds it pointed to a fetch call that was returning a 422 with a validation error — the error was being swallowed by a .catch that only logged to console without updating any UI state. The network request was there the whole time, visible in the session timeline. I just hadn't thought to look for a 422 specifically.
Without /watch I would have opened DevTools, filtered the network tab, probably missed it the first time, then gone and read the source looking for that .catch. Instead I just watched what happened and let the agent read the log.
It pairs well with voice recognition
/watch also has voice recognition built in. So if you're recording a session and want to narrate what you're doing as you go — "clicking the submit button now," "this is where it breaks" — that narration gets woven into the timeline alongside the technical events. When the agent sees the session, it has your narration as context for which moment actually mattered.
That's genuinely useful when you're handing off a session to someone else. The timeline isn't just raw events — it has your annotations attached.
What the agent does with the timeline
lac agent treats the session data like any other file in your project. It can read through the timeline, cross-reference it against your actual source code (since it has project memory via .lac-memory.json), and propose edits directly. If the fix involves changing a fetch handler or adding proper error UI, it'll write the diff and ask you to confirm before touching anything.
You can also just ask it questions about the session in natural language after sending: "why did the form submission fail?" or "what was the last network request before the JS error?" It'll answer from the timeline data it received.
When I reach for /watch
I don't run it constantly. I fire it up when:
- I'm debugging something with a non-obvious failure mode
- I want to audit what API calls a third-party form or widget is actually making
- I'm onboarding a new part of a codebase and want to see what network traffic a user action actually triggers before I read the source
- I need to document a bug for someone else to fix — the session timeline is a much better bug report than a text description
The last one is underrated. Sending a teammate a /watch session timeline instead of a paragraph of "it broke when I did X" cuts the back-and-forth significantly.
Getting started
If you haven't used lac-cli before, install it with:
pip install lac-cli
or grab the one-liner from the lac-cli page. Run lac shell first to set up your provider (Claude, OpenAI, or a local Ollama model), then come back and run lac /watch whenever you have a frontend mystery to solve.
It's one of those tools that sounds niche until the third time you use it, at which point it becomes the first thing you reach for.