Why the NotHoly CLI, not a generic terminal assistant

A terminal assistant that refuses to read a disassembly or draft a payload is little use for security work. One that runs your commands on its own server is worse, because the traffic to your target leaves from an address nobody put in scope. The NotHoly CLI does neither. It runs on your machine, acts only with your approval, and the model behind it takes the work instead of lecturing you. The methodology is in the pentest use case; this is about the tool.

#It runs where your tools are

notholy opens an agent in your project. It can read and search files, edit and write them, and run a command, and it can reach the CVE lookup, the knowledge base and web search. Every command and every write runs on your machine, under your user, and the default mode asks before each one. plan mode is read only, auto-edit writes without asking but still asks to run a command, and yolo asks for nothing and must be set on each run. NotHoly's servers never run anything against your targets. Project notes go in NOTHOLY.md, and file contents and command output are treated as data, never as instructions to the agent, so a planted README cannot redirect it. Slash commands switch the model, the mode and the reasoning effort mid-session, /cost shows what the run has spent, and sessions are saved under ~/.notholy/sessions with owner-only permissions.

#Scope you can enforce

notholy engage records what a test may touch and checks each command against it before it runs. You give it a name, a scope of hosts, wildcards, IPs and CIDRs, a reference to your authorization, and a time window. An in-scope command goes through the normal approval. An out-of-scope target makes you type the host and logs the override, and yolo is off while an engagement is active. Every decision goes to a log.jsonl with the command, the targets, the exit code and a hash of the output, each line chained to the one before, so the record is tamper-evident. The rules live outside the repo, so a repository cannot plant its own scope. The terminal agent docs have the flags.

notholy engage init --name acme-q4 --scope "*.acme-staging.test,10.20.0.0/24" --auth "contract 2026-117"

#Pipe it, or drive other agents

For a one-shot answer, notholy "..." reads standard input, so the tools you already run can feed it.

git diff | notholy "review this diff for injection bugs"

notholy connect and notholy run point Claude Code, Codex or OpenCode at NotHoly models and register a local MCP server with the CVE, advisory and knowledge base tools, so an agent you already use gains that data without a key in its configuration. connect backs up the tool's config first and --undo restores it, and the key stays in the CLI's own login rather than the tool's file. A long session is compacted before it passes the model's context size, with a summary that keeps the goal, the decisions and the findings.

#Where it does not fit

The engagement guard reads the text of a command and does not resolve DNS, so it catches a mistake, not a determined bypass. It is no sandbox, and a command can still reach a host it does not name. yolo runs everything without asking and can change files and run commands you did not read, so keep it for a scratch directory. A command you approve runs with your own permissions, so read the card before you allow it. The CLI needs a login, so it is tied to an account and an e-mail. The model can be wrong like any model, and the output is a draft to check, not a result to trust. It also does not replace the judgment calls: the scope, the authorization and the decision to run are yours.

Keep the commands, the files and the risk on your machine, and let the model do the reading. Install the CLI, then top up a small balance on pricing.