pentesting

pentesting is the public npm facade for the Builder runtime.

• Installs the pentesting CLI.
• Downloads the matching Builder binary from agnusdei1207/builder-public releases for the current OS/CPU.
• Performs only binary resolution and direct argument forwarding before delegating execution to the Rust Builder binary.
• Launches the same runtime with a pentesting banner while keeping Builder as the single internal engine.
• Does not ship a second JavaScript or TypeScript runtime.

Install

npm install -g pentesting
pentesting
pentesting --version

Quick commands

pentesting
pentesting --prompt "Enumerate the target web application and summarize the next actions."
pentesting shell-listener --bind 127.0.0.1 --port 4444
pentesting --version

Inside the interactive TUI:

/goal harden the npm release flow and verify Docker startup
/auto

• /goal <objective> sets the active goal only.
• /goal with no text clears the goal and disables auto mode.
• /auto toggles auto mode for the current goal.
• /auto requires an existing goal and will not infer one from the transcript.
• /auto <text> is rejected with usage guidance; use /goal <objective> first, then /auto.

What npm installs

npm install -g pentesting installs a thin wrapper package and then runs postinstall:

• if BUILDER_BIN is already set, the wrapper reuses that Builder executable
• if BUILDER_SKIP_DOWNLOAD=true, the wrapper skips managed download entirely
• otherwise it downloads the matching public Builder release asset into the package-local managed binary directory and executes that binary on launch

This means the outside package name is pentesting, but the actual runtime engine is Builder.

Thin-wrapper design

The npm package is intentionally narrow and does not keep legacy command translators.

• it installs a launcher, not a second agent runtime
• it resolves or downloads the correct Builder release asset
• it forwards arguments directly into the Rust Builder binary
• it does not translate interactive, run, scan, old target flags, or permission-bypass flags

If a change would add orchestration, memory, monitoring, or prompt-management logic directly into the npm layer, that change belongs upstream in Builder instead.

Runtime strengths exposed through pentesting

Because pentesting delegates to the Rust Builder runtime, it inherits the same core capabilities:

• goal-aware TUI sessions through /goal
• explicit auto-mode toggling through /auto
• post-turn self-review and persistent local memory files
• context compression for long-running sessions
• workflow status, budget, proof, and verification signals in the TUI
• Docker and npm entrypoints that share one runtime instead of diverging implementations
• the explicit shell-listener command for authorized lab multi-session TCP handling with per-session routing, output buffering, and PTY-upgrade helpers

Docker and compose alternative

If you do not want a managed local binary, use Builder directly through Docker:

docker run -it --rm \
  -v "$(pwd):/workspace" \
  -w /workspace \
  agnusdei1207/builder:latest

For the Docker Compose facade, use the public compose.yaml from the public repo or mirrored docs:

PENTESTING_PROJECT_DIR=/path/to/project docker compose run pentesting

Supported runtime targets

Environment variables

Command behavior

• pentesting with no extra arguments starts the Builder interactive/default flow.
• pentesting --prompt "<objective>" runs a direct Builder prompt.
• pentesting shell-listener --bind 127.0.0.1 --port 4444 starts the explicit listener command.
• Arguments are passed through exactly; removed legacy commands are not translated.

Runtime behavior notes

• Docker and npm both end up delegating to the same upstream Builder runtime, so differences are usually install/configuration problems rather than different products.

Runtime cautions

• BUILDER_SKIP_DOWNLOAD=true is only safe when you intentionally plan to provide BUILDER_BIN later or reinstall after provisioning access to the Builder release asset.
• The npm package does not publish Docker images itself. Docker users should treat agnusdei1207/builder:latest as the runtime image and pentesting as the public command/package facade.
• Unsupported OS/CPU pairs fail during release asset resolution before download.
• If the managed binary is missing at runtime, reinstall the package or set BUILDER_BIN explicitly.

Development and release from source

If you maintain this npm facade from the private source repository, use the root builder-private commands rather than adding more logic inside this package:

npm run pentesting:status
npm run pentesting:verify
npm run pentesting:pack:dry-run
npm run pentesting:release:patch:dry-run
NPM_TOKEN=... npm run pentesting:publish -- 0.90.1

Further reading

• public Builder runtime docs and Docker guidance at https://agnusdei1207.github.io/builder-public/
• the mirrored public compose.yaml facade for Docker sessions
• the Builder release asset matching your OS/CPU target

Quietly built across Ireland, Korea, Germany, Italy, the Netherlands, Japan, Belgium, Spain, Portugal, and Austria.

from recon to flag capture, the work speaks for itself.