HuntProxy

Build the image and keep HuntProxy's project data in a named volume:

docker build -t huntproxy:local .
docker volume create huntproxy-data
docker run -d \
  --name huntproxy \
  --network host \
  --shm-size=1g \
  -v huntproxy-data:/data \
  huntproxy:local

Connect your AI agent to the running container:

{
  "mcpServers": {
    "huntproxy": {
      "command": "docker",
      "args": ["exec", "-i", "huntproxy", "HuntProxy", "mcp"]
    }
  }
}

The MCP bridge connects to the HuntProxy daemon already running inside the container.

Optionally, open the web interface at http://127.0.0.1:17890.

[!NOTE] This setup uses host networking because HuntProxy listens on loopback by default. Host-network support is platform-dependent; the native installer is currently the simplest path on macOS.

HuntProxy speaks MCP over standard input/output. When your agent connects, the bridge starts the local HuntProxy daemon automatically and keeps the project available across prompts.

Add this to ~/.codex/config.toml:

[mcp_servers.huntproxy]
command = "/path/to/HuntProxy"
args = ["mcp"]

Restart Codex, then ask it to create a HuntProxy project.

Use this standard JSON configuration in any client that supports local stdio MCP servers:

{
  "mcpServers": {
    "huntproxy": {
      "command": "/path/to/HuntProxy",
      "args": ["mcp"]
    }
  }
}

Replace /path/to/HuntProxy with the absolute path to the binary. It is usually located at ~/.local/bin/HuntProxy—for example, /home/you/.local/bin/HuntProxy.

HuntProxy project create demo https://example.com
HuntProxy project list
HuntProxy project rename 1 "Acme Portal"
HuntProxy project usage 1
HuntProxy project export 1 ./acme-project.huntproxy
HuntProxy project import ./acme-project.huntproxy
HuntProxy har export 1 ./acme-history.har
HuntProxy backup ./huntproxy-backup.sqlite3

Sanitized project exports are for sharing, not recovery: they omit credentials, bodies, replay state, and browser state. For the most complete export, add --include-secrets --include-chromium-profile and protect the result like credentials.

HuntProxy is designed to be the primary web security workbench for an AI agent. It covers the capture, history, browser, replay, fuzzing, discovery, plugin, and evidence workflows agents need, but it is not a pixel-for-pixel Burp clone.

Its defining difference is the operating model: the agent works through MCP, project state survives between prompts, and every important action remains inspectable. You can use HuntProxy on its own for agent-driven testing or alongside existing security tools.

Any AI agent with MCP support on Linux or macOS.

Yes. Run HuntProxy and your agent on a VPS, connect from your phone with Tailscale and SSH, and use tmux or Herdr to keep the session alive.

Not necessarily. HuntProxy mcp starts the daemon automatically. By default, an inactive MCP bridge exits after one hour, and an MCP-started daemon also shuts down after one hour without MCP or UI control activity. Compatible clients can relaunch the bridge when needed. Run HuntProxy serve when you want the workbench to stay active until explicitly stopped.

Projects, captured traffic, findings, managed cookies, Reply and Fuzzer state, and the project's Chromium cookies and site storage are persisted locally. Starting the project browser again resumes its saved workspace. Plugin-generated History entries and saved findings also persist, but plugin job status, result summaries, and resumable analysis checkpoints should be collected before restarting HuntProxy.

By default, HuntProxy stores its database, configuration, browser profiles, CA, logs, plugins, and exports in ~/.huntproxy. Use --data-dir or HUNTPROXY_DATA_DIR to choose a different location.

There are three common ways:

• Load existing cookies: Save the cookies to a UTF-8 file as either a raw Cookie header value or a browser-export JSON cookie array, then ask the agent to load that file into the project for the target URL.
• Log in through the browser: Ask the agent to hand you the project's Chromium browser through CDP. Complete the login, CAPTCHA, or two-factor authentication yourself, then tell the agent to take control back and continue.
• Provide the credentials: Give the agent the username and password and ask it to sign in through the managed browser.

The cookie file must be on the same machine as HuntProxy. A raw cookie file should contain only the value, for example sid=...; csrf=..., without the Cookie: prefix. Credentials shared directly in a prompt pass through your AI client, so prefer a temporary or test account when possible.

Sensitive headers are redacted from ordinary inspection tools but remain available locally for authenticated browsing, replay, and fuzzing. Explicit reveals are audited. The copy_as tool includes sensitive headers by default so its output is runnable; set include_secrets: false for a redacted copy. Protect ~/.huntproxy, full exports, and backups because they can contain sensitive data.

HuntProxy has no HuntProxy-hosted cloud backend: project data is stored locally and its services listen on loopback by default. It still sends traffic to targets you direct it to, through any upstream proxy you configure, and IpRotate communicates with AWS when enabled. Your AI client and model provider may process content returned through MCP under their own privacy terms.

No. Capture scope is not a general outbound allowlist: Proxy, Browser, Reply, and Fuzzer can send requests that are not saved to History. The built-in crawler and plugin host apply tighter scope checks, but you should still give the agent explicit authorization boundaries and monitor the hunt.

Yes. Just ask your agent to hand you the browser. When you are done, ask it to take control back and continue.