OpenHack's recommended first run hands you a hosted account

The recommended first run is an account, not a local model

OpenHack is an MIT-licensed Python tool that describes itself as an open source agentic security scanner, positioned against commercial equivalents from coding-agent vendors with the differentiator that it uses open models exclusively.

The installation is the least interesting part:

pipx install openhack

or with uv, or with pip. Then you run the binary, and this is where the open source framing gets complicated. The documented first-run flow recommends logging in with an OpenHack account, which opens a browser, logs you in, gives you twenty dollars in free credits, and writes a token that the command-line tool then uses automatically.

The environment file shows what that token is for. It is a long-lived bearer credential pointing at a hosted application at one address and a hosted inference service at another, with a development mode that swaps in a local Next.js server and a local inference service run through a command-line worker runtime. So the client is MIT and installable from a package index, while the scanning intelligence and the model access live in someone else's account.

There is a second path through the commands, connecting your own provider credentials directly and choosing from every model your connected providers offer. That is what makes the open-models claim workable, and it is also why the dependency list includes an OpenAI client library.

Four stages, and the last one exploits your app

The pipeline is the design, and it runs in four stages.

Recon reads the codebase, takes any context you supply about the application, and builds a full project model before any hunting starts. That ordering matters: the hunters are not given raw files, they are given a model of the application.

Hunting splits two ways. Category-based hunters each look for a different vulnerability class, covering input validation, access control and data handling among others. Feature-based hunters go deeper on risky code areas, with cross-site scripting rendering, raw SQL and command execution named as examples.

Validation is where the noise gets cut. A separate agent re-reads the suspect code and judges whether the finding is valid at all and what its impact is.

Verification is the part that distinguishes this from a code reviewer. A sandbox command spins your application up inside a Docker container and attempts to exploit each finding with live HTTP requests, and findings that are successfully exploited get a tick. A browser command launches a headless browser against the sandboxed application to confirm client-side issues such as cross-site scripting and cross-site request forgery with real execution rather than inspection. Both are labelled beta, both need Docker, and the documentation is explicit that if the daemon is not running the sandbox command fails with a clear error before the scan starts.

Three grammars, and that is the real ceiling

The dependency list is the fastest way to understand the tool's reach. Alongside the obvious runtime libraries sit tree-sitter and grammar packages for exactly three languages: JavaScript, TypeScript and Python.

That is the limitation to weigh against the feature list. Feature hunters are described as diving into risky code areas such as raw SQL and command execution, and the tool claims to find injection, cross-site scripting, insecure direct object reference and authentication bypass. But a Go service, a Ruby application or a Java backend is not parsed by anything in this dependency set, and the recon stage's project model is built on top of those parses.

The optional extra reinforces the picture. Browser verification depends on Playwright, which is an optional dependency rather than a core one, consistent with it being a beta feature layered on the sandbox.

Two smaller signals in the same list. The console is built on a terminal UI toolkit and a rich rendering library, which is why the interface has findings tabs, a trace tab, arrow-key navigation and mouse toggling rather than plain output. And the project classifiers name macOS and Linux environments without listing Windows, so platform support is narrower than a Python tool might suggest.

A finding is meant to be pasted into another agent

The output design reveals the intended workflow more clearly than the feature descriptions do.

For each confirmed finding the tool gives a severity, a CVSS score, a file location, a full description, the vulnerable code snippet and a recommended fix, all rendered with syntax highlighting in the terminal interface. Then there is a command whose only job is to copy the selected finding, description plus vulnerable code plus fix, so it can be handed to Codex, Claude Code or Cursor.

So the division of labour is explicit: this tool finds and justifies, and a general-purpose coding agent does the edit. That is a sensible division for teams already running coding agents, and it is also an argument about where trust sits. Nothing in the output asks you to accept the fix, and a recommended fix from a model is a suggestion about code you still have to review.

The verification stages are what make the handoff more trustworthy than a plain review, because a finding that has been successfully exploited in a container is a different kind of claim from a plausible code path. The tick marks are the part of this output worth trusting most, and the parts worth trusting least are the severity ratings on findings nobody tried to exploit.

Sessions, pauses and a cost breakdown

A scan is treated as a long-running job rather than a command, and the command list shows it.

There is a pause and resume pair, and interrupting with the usual control key pauses rather than kills. Cancel is separate and permanent. A sessions command browses past scans and reloads them, and it can re-run a scan that was aborted.

Pausing on interrupt is the decision that matters. A full pipeline with recon, several hunters, validators and Docker verification can run for a long time, and the difference between pausing and terminating is the difference between resuming a scan and starting over. It also means the scan state has to survive on disk between runs, which is why past scans are browsable and can be reloaded or resumed.

Cost gets a command of its own, a breakdown for the last scan. For a tool whose selling point is model-driven scanning across multiple agents, a per-scan cost line is not decoration, and the paired login flow that grants twenty dollars of credits at first run tells you the intended unit of use is metered.

Two smaller commands round out the interface. A findings command re-displays the last result without rescanning, and a config command both shows current settings and sets them with a key and a value.

MIT, matching versions, and a plan document in the root

The packaging is in good order, which is worth saying because so much of the surrounding positioning is marketing.

The project metadata reads version 0.2.4, which matches the newest release, and the build backend is Hatchling with the console entry point declared properly. Python 3.11 or newer is required. The classifier marks it as beta, which is consistent with two of its headline features also being labelled beta.

Alongside the package there is an augmentation plan document at the repository root, a third-party notices file, a harness directory, a documentation directory, a scripts directory and a tests directory, with a lockfile for uv. The plan document in the root is the interesting one: it means the intended next steps are written down in the repository rather than only in a roadmap on a website.

The licence is MIT, which for a security tool matters more than for most, since you are about to run it against your own source code and let it start containers and drive a browser. The maintenance signal is healthy rather than exceptional: the last push was on 2026-09-19, and releases 0.2.2, 0.2.3 and 0.2.4 all landed in August 2026, two of them on the same day.

Editorial conclusion

OpenHack suits a team that wants model-driven vulnerability discovery rather than pattern matching, and that will read its findings skeptically, because the validation and verification stages exist precisely to filter the hunters' output. It does not suit a polyglot codebase, since the parser dependencies cover JavaScript, TypeScript and Python only, and it does not suit anyone who needs the whole pipeline to run without a hosted account. Verify first which languages your actual code is in, whether Docker is running before you start a scan, and how much of the reported set you would act on after reading the CVSS scores yourself rather than trusting the tick marks.

Frequently asked questions

Official sources

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