OpenHack: an agentic security scanner that runs a recon-to-verification pipeline on your repo

What problem OpenHack is aimed at, and who it is for

A conventional static analyzer matches patterns. It will tell you that a string reached a SQL call, and it will do so without understanding whether the endpoint is authenticated, whether the parameter is an integer, or whether the code path is reachable at all. The result is a backlog of candidates that a human has to triage. OpenHack's premise is that an LLM-driven agent can read the codebase first, build a model of the application, and then only surface findings that survive a second review and, optionally, a live exploit attempt. The README describes the output as "high quality verified vulnerabilities" rather than a raw candidate list.

The intended user is a developer or appsec engineer working on a repository they control, from a terminal. The project describes itself as being like Claude Code Security or Codex Security but open source and using only open source models. The pyproject classifiers list macOS and Linux, Python 3.11 and 3.12, and a Development Status of Beta. There is no Windows classifier, so treat Windows as unverified.

The framing matters for adoption. This is not a linter you drop into a pre-commit hook. It is an interactive TUI session with a login, a credit balance and a per-scan cost readout.

The recon, hunting, validation and verification pipeline

The pipeline has four named stages, and the README gives a short definition of each. Recon reads the code and builds a project model before any hunting starts, and it also takes custom context you supply. Hunters are category-based agents, each looking for a different vulnerability class such as input validation, access control or data handling. Feature hunters are a second wave aimed at specific risky code areas the README names as XSS rendering, raw SQL and command execution. Validators re-read the suspect code and decide whether a candidate finding is valid, and whether the stated impact holds. Verification is the last stage, and it is the part that distinguishes OpenHack from a text-only review.

Verification comes in two modes, both marked Beta. `/verify sandbox` spins up your application in a Docker container and attempts to exploit each finding with live HTTP requests; findings that are successfully exploited get a check mark. `/verify browser` launches a headless browser against the sandboxed app to confirm client-side issues such as XSS, CSRF and DOM-based bugs. The README states that sandbox verification requires Docker Desktop or any working Docker daemon on the machine where the scan runs, and that if Docker is not running, `/verify sandbox` fails with a clear error before the scan starts. Browser verification inherits the Docker requirement when combined with sandbox.

For every confirmed finding the README says you get severity, a CVSS score, file location, a description, the vulnerable code snippet and a recommended fix, rendered with syntax highlighting in the terminal. The dependency list backs up the code-reading claim: tree-sitter grammars for JavaScript, TypeScript and Python are direct dependencies, so the project parses those three languages structurally rather than treating source as plain text. Playwright is an optional extra under the `browser` group, which is consistent with browser verification being opt-in.

Installing OpenHack and running a first scan

The README gives three install paths. The recommended one uses pipx, which puts the `openhack` console script on your PATH in its own environment:

pipx install openhack

If you use uv, the equivalent is:

uv tool install openhack

And a plain pip install works too:

pip install openhack

The package requires Python 3.11 or newer. Once installed, run the CLI with no arguments:

openhack

On first run the README says you go through a one-time setup. The recommended option is Login with OpenHack account, which opens a browser, logs you in, grants $20 in free credits, and writes a token to the CLI automatically. The `.env.example` file shows the alternative: set `OPENHACK_API_KEY` to a long-lived bearer token you create under /settings/api-keys on the dashboard. That same file also documents `OPENHACK_DEV`, which when set to 1 points the CLI at local dev servers on ports 9080 and 8787 instead of the production endpoints.

With a session open, the README's quick start is to type a slash command pointing at a directory:

/scan .

Use `/scan path/to/repo` for somewhere else. The Trace tab shows live agent activity as recon, hunters and validators run, and the Findings tab shows results when the scan finishes. If you want the exploit stage, `/verify sandbox` is the command to run, and it needs a working Docker daemon first.

Where the design forces a trade-off: hosted inference and credits

The most consequential thing in the README is not a feature, it is the shape of the default setup. The recommended first-run path is an account login that provisions credits, and the `.env.example` points the CLI at `https://api.openhack.com/v1` for inference and `https://app.openhack.com` for the app when `OPENHACK_DEV` is unset. So the default configuration sends your source code to a hosted service for analysis. The README does not document a fully local inference mode, nor does it describe what is retained server-side or for how long. If your codebase cannot leave your network, that is a blocker you need to resolve before installing, and the README is silent on it.

The credit model is the second constraint. The README mentions $20 in free credits on signup and provides a `/cost` command for a breakdown of the last scan. It does not publish a per-token or per-scan rate, so the only way to learn what a full run over your repository costs is to run one and read `/cost`. A multi-agent pipeline that reads the whole codebase in recon and then re-reads suspect regions in validation is, by construction, more expensive per file than a single-pass pattern matcher. That is the price of the extra stages, and it is a real one.

The third trade-off is that verification is Beta and depends on Docker. A finding can be confirmed by the validator and still be unverifiable by exploit, either because the app does not come up in the container or because the vulnerable path needs state the sandbox does not have. The README's check-mark framing implies a binary, but the honest reading is that an unmarked finding is unproven, not false.

Language coverage and the case where OpenHack is the wrong tool

The direct tree-sitter dependencies are JavaScript, TypeScript and Python. That is a strong signal about what the project can parse structurally, and the README does not claim support beyond that set. If your service is Go, Java, Ruby or C, the recon stage has no grammar to work from, and you should assume the project model will be shallow. Nothing in the README says otherwise.

There is a second, sharper case where OpenHack is the wrong tool: deterministic enforcement. The pipeline is non-deterministic by nature. An LLM hunter may or may not surface a given candidate on a given run, and the README describes no rule IDs, no baseline file and no exit-code contract for CI. If your requirement is "fail the build when this exact pattern appears," a rule-based scanner is the right instrument and OpenHack is not a substitute for it. OpenHack is better suited to the exploratory pass: run it before a release, read the findings, and use the `/copy` command to hand a description, snippet and fix to whatever coding agent you use.

A related limitation: the README does not document rollback, resumption guarantees or state recovery beyond `/sessions` and `/pause`. If a long scan is interrupted, the README does not say whether partial findings are persisted. Treat that as unknown rather than assume it is handled.

How OpenHack differs from Semgrep and CodeQL

The closest comparison in this category is rule-based SAST. Semgrep and CodeQL both work by expressing patterns or queries over a parsed representation of your code, and both produce deterministic results: the same commit yields the same findings, with stable rule identifiers you can suppress, baseline and gate on. Their cost is per-CPU-time and effectively zero marginal cost per run. Their weakness is the one OpenHack targets: a pattern that matches a sink cannot tell you whether the source is reachable or the endpoint is authorized, so triage lands on the human.

OpenHack inverts that. The analysis is semantic and agentic, the output is a short list of findings that passed a second review, and verification can go as far as launching a browser against a containerized copy of your app. The cost is that results are not reproducible in the rule-based sense, the pipeline depends on a hosted inference endpoint by default, and the tool is Beta with three releases in the 0.2.x line between 2026-08-07 and 2026-08-21.

The two approaches are complementary rather than competing. A team already running Semgrep or CodeQL in CI would use OpenHack as a pre-release pass on the areas those tools flag as noisy, not as a replacement for the gate.

Editorial conclusion

Adopt OpenHack if you want an LLM-driven first pass over a repository you already own, and you are comfortable sending the scan through the hosted inference endpoint that the device-login flow points at. Do not adopt it as a replacement for a deterministic SAST gate in CI, and do not run it against a third-party codebase without checking what leaves your machine, because the README does not document a fully offline mode. Before relying on it, verify three things yourself: that `/verify sandbox` actually reaches your app through its Docker setup, that `/cost` for a full scan of your repository stays inside the credit you are willing to spend, and that the validator's rejections match your own reading of the code on a sample of findings. The last push to the repository was on 2026-09-05, and the current release line is 0.2.4.

Frequently asked questions

Official sources

1. License: MIT
2. openhackai/OpenHack on GitHub
3. Project website
4. README
5. Releases