Fewer browser round trips, with checked results.

1. How it connects

OpenAI documents local STDIO MCP support. We would expose our own tools through that interface. This is a separate browser workflow selected by the user; it does not patch Codex's hosted inference or automatically replace its built-in browser tools.

Chrome native messaging supplies the extension-to-local-host bridge. A small native host would relay validated messages to the MCP companion through a per-user socket, with pairing and a fixed allowed extension origin. The MCP and Chrome message protocols are different and require an adapter.

The MVP targets macOS and Chrome with TypeScript, a Manifest V3 extension and a Node.js companion. Content scripts read the DOM; a service worker coordinates messages. Permissions are requested for the user-selected tab or explicit public domains, rather than every site. Authenticated dashboards, cross-origin frames, canvas-only interfaces and writes stay outside the first prototype.

2. Where less waiting could come from

This is a design hypothesis: fewer sequential tool/model exchanges may reduce overhead. Benefits depend on whether the agent uses these tools and whether bridge, extraction and checking costs are lower than the work they replace. Dynamic pages can invalidate caches so often that reuse offers no gain.

3. One concrete workflow

Task: read the title and listed price on three public product pages, then return a comparison with source URLs. Codex supplies the approved pages, requested fields and verification rules in one planned call:

read_many({
  pages: [approvedPageA, approvedPageB, approvedPageC],
  fields: ["title", "listed_price", "source_url"],
  checks: ["title_present", "price_present"],
  concurrency: 2,
  deadline_ms: 10000
})

The companion would collect and check these independent reads before returning one structured bundle. Each result would include its page version, captured fields, verification result and observed timings. Missing prices remain missing. Dependent navigation stays ordered; checkout and form submissions are excluded. This example is an interface sketch, not a callable tool or an executed benchmark.

4. Build sequence and release gates

1. Prove the connection first. Deliver a minimal extension, native bridge and MCP companion with one read_current_page tool. Gate: an actual Codex call reads a selected public tab; wrong origins, absent permissions, cancellation and disconnects fail explicitly. This integration has not yet been tested.
2. Add state reuse and grouped reads. Deliver versioned snapshots, narrow field extraction, bounded read_many and outcome checks. Gate: controlled fixtures for navigation, DOM mutation, missing elements, stale state, worker restart and partial failure return correct results without unintended writes.
3. Measure whole tasks. Compare the existing workflow with the companion on ten fixed public, read-only task cases, with five paired attempts each: 100 total attempts. Alternate order, use the same prompt/model/tool versions and conditions, and keep cold and reused sessions separate.
4. Publish evidence before a speed claim. Release a runnable prototype, setup instructions, recorded versions, raw attempts and a report including completion rate, failures, retries, median and p95 elapsed time. A continuation target is a lower median without a worse p95 or completion rate. Small samples remain uncertain; a missed target means narrow the use case or change the design.

No launch date or speedup percentage is promised. The current code controls test result verification, not the connection, cache, batching mechanism or end-to-end browser speed.

5. The trade-offs we must test

A browser extension alone cannot remove model inference time. The agent must opt into the MCP workflow. Installation adds a local companion and permissions, which can outweigh the benefit for simple tasks. Existing tools already provide structured page reads, so the comparison must use a credible existing baseline, not an artificially inefficient one.

The prototype would restrict payload size, tool schemas, tab/domain grants and deadlines; it would omit password fields, input values and browser credentials from snapshots. Page content is untrusted data and cannot change tool permissions or trigger writes. Raw page content stays in the local browser/companion until the user-requested tool result is supplied to their Codex session, where that client's data handling applies. It would not be sent to BrowseSprint's signup backend.

API feasibility is supported by OpenAI's MCP documentation, Chrome native messaging and Chrome content scripts. The proposed architecture and performance targets are our engineering choices, not vendor assurances of compatibility or speed.