A 215-tool catalog sits behind one terminal prompt
HackingTool organizes 215 maintained entries across 21 security categories, including reconnaissance, OSINT, web testing, wireless work, forensics, Active Directory, cloud security, and password auditing. Another 59 archived entries stay hidden unless the operator enables them. Search works by tool name, description, and 63 fixed tags. The application is mainly a launcher and guidance layer around other projects, which is a more accurate mental model than treating it as one scanner.
That distinction makes the product useful. A tester can search a catalog, open an install menu, or start a long-running command in a detached tmux pane without maintaining a personal spreadsheet of project URLs. A headless mode can run a named engagement pipeline and normalize outputs into findings.json, followed by a deterministic Markdown report. HackingTool reduces tool discovery and session bookkeeping. The upstream programs still define what can be tested, what privileges are needed, and how trustworthy each result is.
Three input styles keep discovery separate from execution
The console accepts 3 kinds of input: slash commands, at-prefixed tool or tag names, and plain-English goals. /find searches the bundled catalog before querying GitHub, returns suggestions, and saves chosen discoveries without an install or run command. The README says this path makes zero model calls and refuses requests involving jamming, denial of service, mass targeting, or malware before any network request.
Execution takes a more deliberate route. /goal makes one model call to draft a plan, asks the operator to confirm authorization, and then offers run, skip, edit, or abort for every step. Commands use list-form subprocess calls instead of a shell. Each goal gets a timestamped workspace with the plan, raw output, and run log. Those are sensible controls against accidental execution, but confirmation is still self-attestation. A company with formal rules of engagement needs its own ticketing and approval controls around the terminal.
What happened when we ran it
Our Python 3.12 sandbox installed 40 packages in 25 seconds and used 45 MB on disk. The build completed in 1 second. Pytest then passed 278 of 278 tests in 7 seconds, with 0 failures. Pip-audit found 0 known vulnerabilities in the installed dependency set. commit ef5334f therefore cleared every mechanical check supplied in our lab run.
The checkout contained 135 files, roughly 12,422 lines of source, and occupied 2.7 MB before installation. It included 2 CI workflow files, a Dockerfile, a Compose file, and a tests directory. These figures cover HackingTool's core at the measured commit. We did not install or execute all 215 catalog entries, test commands against a target, or audit the code fetched by their installers. The passing result belongs to the launcher, catalog rules, and included suite.
Safety controls stop at the 215 upstream projects
HackingTool avoids shell execution for planned commands, stores API keys in a mode-600 environment file, pins supported downloads with SHA-256 checks, and keeps discovered GitHub entries inert. Its security policy accepts reports about argument injection, unsafe downloads, prompt injection, privilege mistakes, and catalog integrity. These controls address the parts of the supply chain the project owns.
The same policy explicitly excludes vulnerabilities in nmap, sqlmap, hashcat, and other third-party tools. Optional installations can require Go 1.21 or newer, Ruby, tmux, Docker, and system packages. Some categories include phishing, exploitation, payload creation, and remote administration, so written authorization is a working requirement rather than footer language. A safe trial should use a lab or CTF, inspect the proposed command, and review each upstream project before adding it to a professional workstation.
Python 3.10 is enough for the core, not the whole catalog
The core supports Python 3.10 or newer on Linux and macOS. Pipx is the recommended isolated installation, while uv, a virtual environment, and Docker are documented alternatives. Windows is unsupported and the application exits there. The AI layer is optional: it can call an OpenAI-compatible endpoint, use local Ollama, or fall back to deterministic keyword matching when no model is configured.
GitHub discovery also works anonymously at a documented limit of 10 searches per minute, with a no-scope token raising that figure to 30. The token expands search capacity rather than granting repository permissions. Tool-specific dependencies are where setup stops being small. A successful 25-second core install does not mean nuclei, MobSF, Mythic, or every wireless utility is ready, and it says nothing about driver support or elevated privileges those upstream projects may require.
September issue activity continues without a GitHub release
The repository's last push was August 23, 2026. Issue and pull-request activity continued into September, including a catalog-safety pull request closed on September 24 and open work on the AI layer. GitHub showed 79,681 stars and 133 combined open issues and pull requests when fetched. That is active attention around a widely watched repository, although the combined count is not a bug total.
GitHub's latest-release endpoint returned Not Found, so there was no current release tag to assess. This conflicts with documentation that refers to latest releases, PyPI artifacts, SLSA provenance, and release SBOMs. Until a verifiable artifact is available through the documented channel, the source install is the clearest path. The 278 passing tests make that source credible enough to evaluate, while the missing release record keeps HackingTool below the maturity score its code checks might otherwise earn.