Here’s a practical way to wire Codex CLI to Burp Suite through an MCP server so Codex can inspect Burp HTTP history and help identify likely vulnerabilities.

The safest setup is:

Burp Suite MCP extension → packaged stdio proxy → Codex CLI

That path matters because Codex CLI supports STDIO MCP servers and Streamable HTTP MCP servers, while PortSwigger’s Burp extension explicitly ships with a stdio proxy for MCP clients and documents it as the manual integration route. (OpenAI Developers)

1) Install Codex CLI

Install Codex CLI, then authenticate the first time you run it. OpenAI’s current docs show npm install via @openai/codex, and note that Codex stores MCP configuration in ~/.codex/config.toml by default. (OpenAI Developers)

npm i -g @openai/codex
codex

2) Install the Burp MCP Server extension

Use PortSwigger’s official MCP Server extension in Burp. The BApp page says it exposes Burp functionality through MCP, including access and filtering of proxy history with regex support. (PortSwigger)

In Burp:

1. Open Extensions / BApp Store.
2. Install MCP Server.
3. Open the new MCP tab.
4. Check Enabled.
5. Configure security settings, especially the target approval rules for requests and history access. PortSwigger notes the extension has a configurable target approval system and that data sent to external tools is subject to those tools’ data policies. (PortSwigger)

By default, the Burp extension listens on http://127.0.0.1:9876. (GitHub)

3) Get the packaged stdio proxy from Burp

PortSwigger’s README says the Burp extension includes a packaged stdio MCP proxy server. That proxy forwards stdio MCP traffic from the client to Burp’s local MCP web server. (GitHub)

You have two ways to get it:

• easiest: use the extension’s installer/export option from the Burp MCP tab
• or build the extension yourself and extract/build the packaged proxy as documented

If you build from source, PortSwigger’s README says:

git clone https://github.com/PortSwigger/mcp-server.git
cd mcp-server
./gradlew embedProxyJar

That produces build/libs/burp-mcp-all.jar. (GitHub)

4) Confirm Java is available

The Burp MCP extension build/install docs require Java in PATH, and the stdio proxy example also runs with Java. (GitHub)

java --version

5) Add the Burp MCP server to Codex CLI

OpenAI documents two ways to register MCP servers in Codex:

• codex mcp add ...
• edit ~/.codex/config.toml directly

For STDIO servers, Codex expects a command plus optional args, env, cwd, and timeouts. (OpenAI Developers)

Recommended: configure ~/.codex/config.toml

Add this block:

[mcp_servers.burp]
command = "java"
args = [
  "-jar",
  "/absolute/path/to/mcp-proxy-all.jar",
  "--sse-url",
  "http://127.0.0.1:9876"
]
startup_timeout_sec = 20
tool_timeout_sec = 120
enabled = true

That command shape comes directly from PortSwigger’s documented stdio proxy invocation, adapted to Codex’s stdio server config format. (GitHub)

Alternative: add it with the Codex CLI

OpenAI’s Codex MCP docs show the general pattern:

codex mcp add <server-name> -- <stdio-server-command>

So your Burp command would be conceptually:

codex mcp add burp -- java -jar /absolute/path/to/mcp-proxy-all.jar --sse-url http://127.0.0.1:9876

The exact add syntax is consistent with OpenAI’s MCP docs for stdio servers. (OpenAI Developers)

6) Start Burp first, then launch Codex

Start Burp with the MCP extension enabled before starting Codex, because the stdio proxy connects to the Burp MCP endpoint on localhost. PortSwigger’s docs describe the proxy as a bridge to the Burp instance hosting the MCP web server. (GitHub)

Then run:

codex

Inside Codex, use /mcp to inspect active MCP servers; OpenAI’s docs say the TUI exposes active MCP servers there. (OpenAI Developers)

7) Verify the connection

A simple smoke test in Codex is:

“List the available tools on the burp MCP server and tell me which ones can read proxy history.”

That matters because the exact Burp tool names can vary by extension version, while the official PortSwigger docs only guarantee that the extension can access and filter proxy history and expose Burp functionality as MCP tools. (PortSwigger)

8) Narrow Burp’s scope before analysis

Before you let Codex analyze traffic, set guardrails in Burp:

1. Use a dedicated Burp project for the target.
2. Define approved targets in the MCP extension settings.
3. Keep configuration-editing tools disabled unless you specifically need them.

PortSwigger explicitly calls out security settings, target approval, and optional config-editing permissions. (GitHub)

9) Run HTTP history analysis from Codex

Once the MCP link is live, your workflow in Codex should be:

1. Ask Codex to enumerate Burp MCP tools.
2. Identify the tool that reads proxy history.
3. Pull a small batch first, filtered to your target host.
4. Ask Codex to cluster traffic by endpoint, auth state, content type, status code, and interesting parameters.
5. Then ask it to flag suspicious patterns.

A good first command in Codex is:

Use the burp MCP server only. First list burp tools, identify the one for proxy history, then fetch a small sample of HTTP history for the target host only. Summarize what fields are available before doing any deeper analysis.

10) Use this Codex prompt for Burp HTTP history analysis

Paste this into Codex after the MCP server is connected:

Use the Burp MCP server to analyze Burp Suite HTTP proxy history for possible vulnerabilities.

Process:
1. First list the Burp MCP tools available to you and identify the tool(s) that can read or filter proxy history.
2. Pull HTTP history only for the approved in-scope target(s). If tool parameters allow filtering, prefer:
   - target host / domain
   - status codes
   - content type
   - methods
   - regex filters for paths, parameters, cookies, auth headers, tokens, and error text
3. Build an endpoint inventory grouped by:
   - scheme, host, port
   - method
   - normalized path
   - query parameter names
   - status code patterns
   - content type
   - authentication state
4. Highlight likely attack surfaces:
   - login, logout, registration, password reset, MFA, OAuth, SSO
   - file upload / download
   - search / filter / sort
   - admin or internal endpoints
   - APIs using JSON, GraphQL, XML, multipart, or serialized data
   - redirects, SSRF-like fetchers, webhooks, import/export, PDF generation
5. Flag likely vulnerability indicators from history alone, including:
   - IDOR / access control issues
   - missing auth on sensitive endpoints
   - privilege boundary inconsistencies
   - reflected input suggesting XSS
   - dangerous server errors or stack traces
   - SQLi / template injection hints in parameters or responses
   - SSRF indicators (URL parameters, remote fetch features)
   - open redirects
   - file upload validation weaknesses
   - CSRF-sensitive state-changing endpoints
   - insecure cookies, missing security headers, CORS misconfigurations
   - version disclosure, debug endpoints, backup files, hidden APIs
6. Correlate repeated requests to find:
   - same endpoint behaving differently across roles / sessions
   - predictable object IDs
   - parameter tampering opportunities
   - unusual 401/403/200 transitions
7. Produce output in this format:
   A. Executive summary
   B. Endpoint inventory
   C. Highest-priority suspected issues
   D. Evidence from HTTP history
   E. Suggested manual verification steps in Burp
   F. Suggested follow-up prompts for deeper analysis
8. Do not claim a vulnerability is confirmed unless the HTTP history clearly proves it. Label findings as:
   - observed
   - suspicious
   - likely
   - confirmed
9. Be concise but specific. Quote exact paths, methods, parameters, headers, cookies, and response clues when relevant.

11) Use this tighter prompt when you already know the target host

Use the burp MCP server to analyze proxy history for host example.com only.

Tasks:
- enumerate Burp MCP tools and pick the history-reading tool
- fetch and filter history for example.com
- cluster requests by normalized path and method
- identify unauthenticated vs authenticated endpoints
- flag possible IDOR, auth bypass, SSRF, XSS, SQLi, open redirect, CSRF, file upload, CORS, cookie, and security-header issues
- rank the top 10 suspicious endpoints by exploitability and impact
- for each top endpoint, give the exact evidence from history and one manual Burp verification step
- end with a short list of the best next requests to send in Repeater

12) Optional: try direct HTTP MCP instead of the stdio proxy

OpenAI says Codex supports Streamable HTTP servers configured with a url in config.toml. PortSwigger says Burp can also be connected to as an MCP server at http://127.0.0.1:9876 or sometimes http://127.0.0.1:9876/sse, depending on client behavior and configuration. (OpenAI Developers)

Because PortSwigger’s Burp docs describe that endpoint as SSE mode, and OpenAI’s docs specifically describe Streamable HTTP, I would treat direct URL config as a version-dependent experiment rather than the default path. The stdio proxy is the more reliable setup for Codex right now. (OpenAI Developers)

13) Common failure points

If Codex does not see Burp:

• Burp is not running
• the MCP extension is not enabled
• the stdio proxy JAR path is wrong
• Java is not in PATH
• the Burp MCP listener is not on 127.0.0.1:9876
• target approval rules are blocking history access

Those checks line up with PortSwigger’s documented enablement flow, default listener, and security controls. (GitHub)

Minimal working setup

If you only want the smallest useful configuration, this is it:

~/.codex/config.toml

[mcp_servers.burp]
command = "java"
args = [
  "-jar",
  "/absolute/path/to/mcp-proxy-all.jar",
  "--sse-url",
  "http://127.0.0.1:9876"
]
enabled = true
startup_timeout_sec = 20
tool_timeout_sec = 120

Then:

codex

And in Codex:

Use the burp MCP server. List Burp tools, find the one that reads proxy history, fetch a small sample for the in-scope target, and summarize likely vulnerability candidates.