[Feature]: Add network inspection and persistent page overrides to the integrated browser

[pantharshit007]

Before submitting

• I searched existing issues and discussions and did not find a duplicate.
• I am describing a concrete problem and use case.

Area

apps/desktop (integrated/collaborative browser and its automation tools)

Problem or use case

The integrated browser is useful for viewing and interacting with the same page as an agent, but debugging a web app still requires switching to an external browser or Playwright tooling for capabilities such as inspecting network traffic and overriding page responses. That splits the debugging workflow across different browser sessions and makes it harder for the user and agent to inspect the same state.

For example, I want to inspect a failing API request in the integrated browser, temporarily replace a response with local content, refresh the page, and keep that override active while I test the UI.

Proposed solution

Expand the integrated browser's debugging capabilities, with matching agent-accessible operations where appropriate:

• Network inspection: Capture and filter requests and responses for the active tab, including URL, method, status, timing, and relevant headers/body. Allow inspecting failures and optionally preserving the log across navigation.
• Persistent page overrides: Let a user or agent override a selected response or page resource with edited/local content, scoped to a tab or project. Reapply the override after refresh and navigation until it is disabled or removed. Make active overrides visible and easy to clear.
• Follow-on debugging features: Console messages, request blocking or mocking, and a HAR export would help close other gaps with Playwright/DevTools workflows.

Why this matters

It would let users and agents debug the page they are already sharing in T3 Code. A reproducible override is especially useful for testing loading, empty, error, and edge-case UI states without repeatedly changing the app or backend.

Smallest useful scope

For one active tab: a filterable request log with request/response details, plus a URL-matched response override that survives refresh within that browser session and can be toggled off. Additional controls and longer-lived persistence can follow later.

Alternatives considered

Using Playwright or an external browser provides these tools today, but it moves inspection and overrides away from the integrated collaborative tab.

Risks or tradeoffs

Network bodies can contain credentials or personal data. The UI and any agent-facing output should limit capture size, redact sensitive headers by default, and make capture/override state explicit. Overrides also need clear scope so they do not unexpectedly affect unrelated tabs or environments.

Examples or references

• Related: [Feature]: t3 browser CLI — drive the collaborative browser without MCP #7469 proposes a CLI for driving the same collaborative browser. This request is about additional browser debugging capabilities regardless of whether they are exposed through a CLI or MCP tools.
• Related: preview_snapshot has no scoping option and costs ~17k tokens plus a PNG per call #9200 discusses the size and scope of preview_snapshot output. Network inspection should support targeted queries instead of adding every request to snapshots.

Done by GPT-6 sol 🤖

[juliusmarminge]

Triage

Confirmed against current main. The integrated browser already keeps a thin failure log and a console stream for the agent, and the preview menu can open detached DevTools. It does not record successful requests, headers, bodies, or timing, and it has no response override. This is a feature request, not a bug.

What the code does

Automation attaches one CDP debugger per preview webContents and enables Runtime, Accessibility, Network, and Log (ensureControlSession in apps/desktop/src/preview/Manager.ts). A second debugger client is refused: if DevTools is open, or any debugger is already attached, automation fails. Open DevTools in the preview menu (apps/web/src/components/preview/PreviewMoreMenu.tsx) calls openDevTools, which detaches that control session, opens DevTools detached, and reattaches when DevTools closes. The user gets Chromium's Network and Console panels, but not while an agent holds the debugger, and the agent cannot see that panel.

What the agent gets is consoleEntries and networkEntries on preview_snapshot (PreviewAutomationSnapshot in packages/contracts/src/previewAutomation.ts).

Console is already captured. Runtime.consoleAPICalled, Runtime.exceptionThrown, and Log.entryAdded become {level, text, timestamp, source}.

Network is failures only. Network.requestWillBeSent stores {url, method} in a private map. Network.responseReceived appends a networkEntries row only when status >= 400. Network.loadingFailed appends a row with status: null and errorText. Network.loadingFinished drops the in-flight request and does not log 2xx or 3xx. PreviewAutomationNetworkEntry is {url, method, status, failed, errorText, timestamp}. Headers, bodies, resource type, and timing are not copied. There is no Fetch domain, no webRequest handler, and no response override.

The buffer is per webContents, capped at 200 (DIAGNOSTIC_BUFFER_LIMIT), and is not cleared on navigation. It is cleared when the control session detaches, including when DevTools opens. The MCP layer then keeps the newest 40 console rows and 40 network rows, cuts each string at 500 characters, and sheds networkEntries early if the snapshot text exceeds 60 KB (boundSnapshotMetadata in apps/server/src/mcp/McpHttpServer.ts). There is no URL filter. The web UI never renders these arrays.

Related work

• Discussion #7469 proposes a CLI for driving the same collaborative browser. That is about the control surface, not network inspection or overrides.
• Discussion #9200 (closed) is about preview_snapshot size and scoping. Network inspection should stay a targeted query rather than dumping every request onto snapshots.
• #8037 (closed not_planned) asked for richer preview diagnostics / all-status network capture. Adjacent, not this full request log + override ask.
• #10501 (merged) bounds snapshot text so a large log cannot blow the tool result. #7302 (open) would stop collecting console and network unless preview_snapshot passes include. Neither adds a request log or an override. Putting every request on the snapshot would fight both.

Next step

Keep this issue for the gap the failure log does not cover. A useful first cut:

1. A separate query for one tab, filtered by URL, returning method, status, timing, and size-capped headers and body, with sensitive headers redacted. Leave preview_snapshot as the failure-and-console summary it already is.
2. A tab-scoped URL override on that same debugger session, reapplied after refresh until it is cleared, and visible in the preview UI.
3. Leave a user console panel, request blocking, and HAR export for later. Console messages are already on the snapshot, and DevTools remains the user panel while the agent is not attached.

Until then, failures and console text are on preview_snapshot, and the Network panel is the detached DevTools window from the preview menu. Opening it pauses agent automation until it is closed.

[DavidMendesOS]

An update for anyone picking this up: since #15328, preview automation runs on Playwright on the server (apps/server/src/preview/ServerBrowser.ts), not on the desktop CDP session the triage above describes. That makes the override half of this much cheaper. page.route() and context.addInitScript() are already available on each tab, so no Fetch-domain plumbing or debugger-sharing with DevTools is needed.

I'd like to propose a narrow agent-only first cut, scoped to one tab and cleared when the tab closes:

• preview_route: match a URL glob (optionally a method) and either fulfil it (status, headers, body), abort it (errorCode), or let it continue. List the active routes in preview_status, and clear them by id or all at once.
• preview_init_script: register a script that runs before any page script on every navigation in that tab, with its return value or captured state readable through preview_evaluate.

My use case is QA and end-to-end flows I currently run in Playwright and would like to run on the T3 preview tools alone:

1. Answer one backend call with a 503 to check the app's error state, without changing the backend.
2. Get hold of the app's WebSocket before the app starts (an init script wrapping WebSocket) so a test can drop the connection mid-flow and check reconnection.

Network inspection, the UI for overrides, and persistence beyond the tab could come later. If the direction is acceptable, I'm happy to put up a PR for whatever scope you approve.