KaliGPT HackerX: an agentic AI assistant wired into the Linux shell

A shell wrapper that puts model choice behind one command

KaliGPT is described in the README as an agentic assistance in Linux CLI for ethical hacking and cybersecurity, an AI that helps with the command line so that a learner can study security with less friction. The current branding is HackerX, and the help output calls it HackerX, KaliGPT v1.3, with the credit line naming SudoHopeX and Krishna Dwivedi.

What it actually is, structurally, is a single command, kaligpt, that takes an optional mode and an optional prompt. The mode selects which model backend answers. The default is Gemini, and the mode list in the help output is the clearest description of the project's scope.

Usages:
        kaligpt [MODE(Optional)] [Prompt(Optional)]

MODES:
    -g  [--gemini]            =  use Gemini models (Online)
    -o  [--ollama]            =  use local models via Ollama (Offline,cloud:online )
    -or [--openrouter]        =  use OpenRouter models (Online)
    -c  [--chatgpt]           =  use OpenAI models (Online)
    -ll [--litellm]           =  use 100+ providers via LiteLLM (Online)
    --web                     =  AIs official Web-Chat Opener (Online)
    --setup-keys              =  setup API keys for online models
    -u [--update]             =  update KaliGPT to latest version
    -v [--version]            =  show KaliGPT version and exit
    -lr [--list-providers]    =  list KaliGPT available providers (vendors)
    -h  [--help]              =  show this help message and exit

Two things follow from that list. The first is that the project is a routing layer, not a model, and it is explicit about where the intelligence comes from. The second is that a LiteLLM mode exposing more than a hundred providers is the general case, and the named backends are conveniences for the common ones.

The offline option is the one that matters most for a security workstation, where sending shell output or captured traffic to a hosted provider is a decision rather than a default. The Ollama mode is marked as offline, and it is the one a cautious user would reach for first.

The install is a curl piped into bash, and that is the first thing to check

The installation section is two steps, and the first is a remote script executed directly.

    curl -sL https://raw.githubusercontent.com/SudoHopeX/KaliGPT/refs/heads/hackerx/install.sh | bash

The README attaches a note to it: use within permitted directory without root user. Then the second step runs the installer that has been fetched, with a parenthetical instruction not to use sudo in Termux.

   sudo bash kaligptinstaller.sh

The shape of this deserves an explicit word, because it is a common shape and it carries a real risk. Piping a script from a URL into bash means the code that runs is whatever is at that URL at that moment, with no review, no checksum and no record of what you executed. The URL points at a branch, not a tag, so the content of the script can change between the moment you read about it and the moment you run it. The releases list shows tags up to v1.3.6, published on 2026-06-25, and the default branch of the repository is hackerx, which is the branch the install command fetches from.

The reasonable approach is to download the script, read it, and then run it. That is what the repository layout invites, since install.sh is a file in the top level of the repository alongside the installers directory, so the script is available to inspect before it ever runs on a machine. The two-step form, where the installer script is present on disk and can be read, is the part of the flow that is safe by construction; the curl pipe is the part that removes that opportunity.

The Termux note also matters, since it points to a genuine difference between an Android environment and a normal Linux box. Running the installer with sudo on Termux, which has no root and a different package model, fails in ways that do not make sense on a desktop.

Tool calling and web search, which is the agent part

The feature badges in the README list CLI interface, tool calling, online search, choice of AI backend, automated installation and Termux support. Two of those are the substance of the project.

Tool calling is what separates this from a chat wrapper. The help output lists a set of slash commands under Model Management, and one of them is the one that matters.

Model Management:
    /change-model             = change to a different AI model
    /reset-to-default-model   = reset to KaliGPT default AI model (Gemini)
    /list-tools               = list available tools for AI Agent

A tool that the model can call is a difference in kind rather than in degree. A model that can only produce text can tell you which nmap flags to use; a model that can run a command can check whether the host is up first, adapt, and report what it found. That is why a project aimed at security learning cares about tool calling, and it is also why the risk profile changes. The same mechanism that lets the assistant run a reconnaissance command on your own request is the mechanism that would let it run one you did not think about.

Online search is the second capability, and the README links it to a separate project, OpenSearchAPI, by the same author. Combining search with tool calling gives an agent that can look something up and then act on it, which is a large step in autonomy from a model that only answers. The badge for online search is separate from the tool calling badge, which suggests the two are pluggable rather than always on.

The repository layout supports that reading. There is an agents directory, a requirements directory with a globals document, an installers directory, a tests directory, and separate DISCLAIMER.md, SECURITY.md, CONTRIBUTING.md and DEVELOPER.md files, which is a more complete project hygiene than a single script usually carries.

What the project itself warns about

The README carries a disclaimer section with a warning block, and it is unusually direct.

The first point is that HackerX, KaliGPT v1.3, is in active development, so the project says not to expect it to work flawlessly, and points contributors to raising an issue or sending a pull request instead.

The second point is about lawful use. The text states that access to the library and use of the information or any portion of it is not intended and is prohibited where such access or use violates applicable laws or regulations, and that by no means do the authors encourage or promote unauthorized tampering with running systems, since that can cause serious human harm and damage to property. The closing sentence asks readers not to use the source code for cybercrime.

This is a legal and ethical framing rather than a technical one, and it is worth reading as a constraint on the tool's use rather than as boilerplate. An agent with tool calling and web search will attempt things, and on a machine that is connected to real targets the difference between a sanctioned engagement and an unauthorised one is a matter of scope and permission, not of the assistant's intent. The disclaimer is the project's statement of where it expects to be used, and it is also the boundary a user is responsible for maintaining.

The licence is recorded as a custom licence that GitHub cannot classify, so the terms are in the LICENSE file rather than in the metadata field, and a separate SECURITY.md exists for responsible disclosure. The README header also notes an updated date of 14 feb 2026, and the last push was on 2026-10-19 on the hackerx branch, so the project is being worked on rather than abandoned.

Against a plain terminal assistant and against a model of your own

There are two reasonable alternatives, and they differ from KaliGPT in ways that matter for a decision.

The first is a general purpose AI assistant in the terminal, of the kind that wraps a model and gives it shell access. The difference in approach is the scoping. KaliGPT is built around the Kali security distribution and the topics that come with it, and the repository topics name the kali, kali-linux-tools, kali-scripts and kali-tools vocabulary directly, with an automated installation path and a requirements document dedicated to the environment. A general assistant would give you the same model and similar tools without any of the Kali-specific setup, and would be a smaller thing to reason about.

The second alternative is to run the model yourself with Ollama and skip the CLI layer entirely, using a model you host, with your own prompt and your own tools. That is the strongest privacy position of the three, because nothing about your session leaves the machine, and the Ollama mode inside KaliGPT gets you part of the way there while keeping the convenience of the project.

The case for KaliGPT over both is convenience and coverage. One command, a set of interchangeable backends, a key setup path, tool calling already wired up, search already wired up, and an installer that sets up the environment instead of a list of steps to follow. The case against is the same thing seen from the other side. The layer between you and the model is code you did not write, it is updated from a branch, and it decides which backend sees your prompts and what the model is allowed to run. A user who cares about exactly that boundary can use the Ollama mode and keep the traffic local, and a user who does not care should be aware that the default is an online model.

Editorial conclusion

KaliGPT fits a learner or practitioner on a Kali workstation who wants a model that can call local tools and search the web without leaving the terminal, and it does not fit anyone who needs predictable output, because the same prompt against different backends can behave differently and the project itself warns that it is in active development. Before running it, read the install.sh file the curl command fetches rather than piping it straight into bash, run it inside a permitted directory and without root as the README instructs, and decide which backend to use first, since the local Ollama mode keeps the traffic on the machine while the online modes send your prompts and tool output to a provider.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. SudoHopeX/KaliGPT on GitHub