Caido Skills
The official Caido skill for agents: search HTTP history with HTTPQL, test requests through the Caido proxy, add replace rules and hand findings to Replay
- 286 ★ on the repository
- Last commit
- MIT
Broad access
Why this level
- The agent sends real requests to the target with the cookies and authorization headers taken from Caido history
- Match and replace rules change the traffic that passes through your Caido
- The PAT token gives access to your Caido instance, and its history can hold other peoples secrets
Install
- Works in
In your terminal, with SkillFoxx CLI
npx skillfoxx add skills/caido-skillsDetects the agents on your machine, shows the access level and pins the version.
Other ways to install
Access and checks
How we reviewBroad accessThe tool can change data, run commands or handle secrets.
- The agent sends real requests to the target with the cookies and authorization headers taken from Caido history
- Match and replace rules change the traffic that passes through your Caido
- The PAT token gives access to your Caido instance, and its history can hold other peoples secrets
This is third-party code. Review the repository files before installing.
What it does
Caido Skills is the repository of the Caido proxy developers with the caido-mode skill. It is a command-line client on top of the Caido API built on the official @caido/sdk-client: each command runs as npx tsx caido-client.ts <command> and prints JSON. The agent searches HTTP history in the HTTPQL language and manages interception, match and replace rules, findings and Replay sessions. The skill sets the workflow. For testing, the agent finds a request in history with the right authorization, saves its headers and cookies once into a config file with export-curl --config, and then runs curl -K through the Caido proxy so every request lands in history. For a handoff to a human, the agent creates a named Replay session inside a named collection. The instructions tell the agent to run bulk brute-forcing and batches of 100 or more requests outside Caido so the history does not bloat.
Who it is for. For web application security testers and bug hunters who work in Caido and want to delegate the history digging and request checks to an agent.
Good fit when
- You need to find requests to a specific host and path in HTTP history with an HTTPQL query such as req.host.cont:"target.com"
- You want to check an endpoint for ID substitution by repeating a request with someone else ID through curl so every probe stays in history
- You need to test path normalization: the skill requires curl --path-as-is so ../ does not collapse on the client
- You want to add a match and replace rule without opening the Caido interface
- A finding has to go to a colleague: the agent assembles a named collection of Replay sessions
Not a fit when
- You need bulk brute-forcing and fuzzing: the instructions run ffuf and batches of 100 requests or more directly, outside Caido
- You have no running Caido and no access token: the client works only on top of its API
- You have no permission from the system owner to test it: the skill is built for security testing
- You need a tool for another proxy: the skill is tied to the Caido SDK and HTTPQL
Example request
Find requests to /api/user on target.com in Caido history, save the auth into a curl config and check whether the endpoint returns other profiles when the ID is swappedLimitations
A running Caido instance is required. For sign-in the skill recommends a personal access token (PAT). The client is written in TypeScript and runs through npx tsx, so the machine needs Node.js. Installation docs and examples are at docs.caido.io.
The repository currently holds one skill folder, skills/caido-mode, although the README calls it a collection.
How to disable. Delete the caido-mode folder from the agent skills directory, which is ~/.claude/skills/caido-mode for a global install. Revoke the PAT token in Caido settings.
FAQ
How do I install the Caido skill in Claude Code?
Run pnpm dlx skills add caido/skills --skill='*', and add -g for a global install. A step-by-step walkthrough is on the skills page of the Caido docs.
Why test requests through curl instead of Replay?
That is what the instructions say: probes go through curl -K with a saved auth config and the Caido proxy, every request stays in history, and long cookies and tokens stay out of each command. Replay sessions are for handing a request to a human.
What is HTTPQL and why does the agent need it?
HTTPQL is the query language for HTTP history in Caido. The search command takes expressions such as req.host.cont:"target.com" AND req.path.cont:"/api/user", so the agent finds the request without paging through the interface.
How does the skill hand a finding to the user?
Through a named Replay session: create-session <id> --name ... or send-raw ... --name ... for a hand-built request. For several requests it creates a named collection. For running outside Caido the agent supplies a full self-contained curl from export-curl.
What can the caido-client do?
The sources have separate modules for request history, findings, interception, match and replace rules, Replay, management and instance info. Tests cover curl export, replace rules and raw request editing.
Discussion
No questions or reviews yet.
Related
SkillsA practical security skills base for agents: web, API, privilege escalation, Active Directory, mobile, binaries and crypto
A security scanner for agent skills: finds prompt injection, data exfiltration and malicious code before you install
An authorized bug-bounty suite: 50 subagents, 26 commands and 2 bug-bounty-platform MCP servers for Claude Code, Codex and five more agents
Security scanner for agent skills and MCP servers: finds prompt injection, data exfiltration and supply chain risks before install
VibeSec
VibeSec-Skill
A secure coding skill: the agent looks at code from a bug hunter's perspective and prevents common web vulnerabilities
A code security audit skill by Cloudflare: the agent runs recon, coverage-led hunting and independent verification of findings, then produces a structured repor
Comparison with similar tools
Entries that share the main search query, and how they differ.
| Entry | Official | Authentication | Repository stars | Main difference |
|---|---|---|---|---|
| Caido Skills (this entry) | yes | 286 | ||
| Burp Suite MCP Server | yes | not required | 1,261 | an extension for Burp Suite, a different proxy, connected over MCP |
| pentest-ai-agents | no | 2,378 | a set of Claude Code subagents for the whole pentest cycle, not tied to one proxy | |
| Charles MCP Server | no | API key | 331 | an MCP server for Charles Proxy |
README in short
The description briefly presents the repository as a collection of skills for working with Caido and points to the docs for a full setup guide. The only install command goes through pnpm dlx skills add, with a global variant, and tool details live in the skills repository from Vercel. The skills list section in the README is empty, and the contents are visible in the skills/ folder.
README badge
Original SKILL.md
--- name: caido-mode description: Full Caido SDK integration for Claude Code. Search HTTP history with HTTPQL, test with curl proxied through Caido (caching auth in reusable static curl config files), add match & replace rules, and organize handoffs into named replay sessions and collections - all via the official @caido/sdk-client. PAT auth recommended. tags: [worker] --- # Caido Mode Skill A CLI over Caido's API (built on the official `@caido/sdk-client`) for HTTP-history-driven testing. The tool lives at `~/.claude/skills/caido-mode/caido-client.ts`; every command is `npx tsx caido-client.ts <command>` and outputs JSON unless noted. ## How to operate (read this first) There are **two distinct modes**: 1. **Testing → use `curl`, always proxied through Caido.** Find a real authenticated request in history, cache its auth into a reusable curl config (a faithful static snapshot of its headers + cookies), then probe with `curl -K auth.cfg "$BASE/path"`. **All traffic must go through Caido** (the config carries the proxy), so every request lands in HTTP history. 2. **Handoff → use replay sessions + collections.** Only when handing a request (or a set) to the *user* do you materialize it as a named replay session inside a named collection. Hard rules: - **Everything goes through Caido — except high-volume bruteforce/fuzzing.** Never curl a single target request directly; always via the Caido proxy (the generated config does this; otherwise add `-x <proxy>`). **The one exception:** don't proxy bruteforce/fuzzing tools (`ffuf`, etc.) or any batch of **100+ requests at once** through Caido — it bloats HTTP history. Run those **direct** (no `-x`), then bring any interesting hit *back* into Caido (re-send it through the proxy / promote to Replay) to investigate and hand off. - **Test with `curl`.** Don't spin up replay sessions for probing — that's handoff only. - **To show the operator a request, send it to Replay.** Whenever you want the operator to *see* a specific request, create a **named replay session** for it (in a named collection if there's more than one) — that's how they inspect and re-run it in Caido. A request you tested via curl only becomes something the operator can work with once you promote it into Replay (`create-session <id> --name …`, or `send-raw … --name …` for a crafted one). - **Cache auth in files, don't re-paste it.** Use `export-curl --config` once per target; then reference the config. Don't dump cookies/JWTs into every command (or repeatedly into context). - **If you hand the operator a runnable command, make it a FULL self-contained curl** (all headers inline, via `export-curl`) — for a PoC or something they'll run outside Caido. The `-K` config is for your internal testing only; never hand them a `curl -K /tmp/…` line. - **Replay session names are mandatory**, and editing a session forces explicit name intent. - **Use collections for multi-request handoffs**; refer to sessions/collections by **name, not ID**.