DevSnoopDevSnoop

Browser debugging

Capture Fetch Request Bodies Before Editing Frontend Code

Published June 26, 2026

When an agent fixes a broken frontend flow, I want it to check the request body before it edits the component. A bad payload points to state, serialization, or form mapping. A good payload with a bad response points somewhere else.

The simple version is to capture the fetch request, redact sensitive fields, then decide what code to open.

The Problem

Screenshot loops miss this class of bug. The page can look wrong because the browser sent the wrong JSON, because the server rejected the right JSON, or because the UI crashed after a good response.

I see this with login, checkout, license activation, search filters, upload metadata, invite forms, analytics events, and admin tools. The visible symptom is usually that the button does not work.

That sentence is not enough. I want the agent to answer what the browser sent.

How I Want Agents To Check It

I use DevSnoop for this because it gives the agent a small HTTP command instead of a whole DevTools session to reason through. 

curl -s -X POST http://127.0.0.1:9400/ \
  -H 'Content-Type: application/json' \
  -d '{
    "command": "get_network",
    "params": {
      "urlPattern": "/api/",
      "includeRequestBody": true,
      "includeResponseBody": true,
      "bodyMaxBytes": 12000
    },
    "tabID": 123
  }'

Bodies are off by default. When requested, DevSnoop asks Chrome's debugger API for the request post data and response body for matching network entries. It redacts common secret-shaped fields by default, including token, password, secret, cookie, authorization, CSRF, session, API key, license key, and private key.

That keeps the workflow inside the existing debugger permission and avoids shipping a generic execute-script command just to see what JSON the page sent.

What The Agent Can Decide

A request body changes the next edit.

  • If no request appears, I check the click path, validation branch, or disabled state.
  • If the request body has stale values, I check state wiring and serialization.
  • If the body is right and the response is 401, I check auth.
  • If the body is right and the response shape changed, I check the UI reader.
  • If the response is right and the DOM is wrong, I check feature state and rendering.

This saves a lot of pointless edits. The agent does not need to guess whether the bug is in the button, the form, the API client, or the response handler. It can inspect the browser evidence first.

Why Not A Raw Script Command?

A raw script command is powerful. It is also a broad feature to ship in a Chrome extension. Chrome Web Store review is easier when the extension exposes packaged, purpose-built commands instead of arbitrary JavaScript execution.

For this job, request body capture is enough. Chrome already exposes the data through the debugger protocol. DevSnoop just returns it in the same structured shape agents already use for logs, screenshots, DOM summaries, and diffs.

The Command I Use First

{
  "command": "get_network",
  "params": {
    "urlPattern": "activate|checkout|search",
    "includeRequestBody": true,
    "includeResponseBody": true,
    "bodyMaxBytes": 12000
  }
}

Then I ask the agent to summarize only the relevant request, including method, URL, status, redacted payload, redacted response, and the console error that happened after it.

Sources