Post cover image
STRIX

September 2, 2026

FREE PENTEST TOOL

Strix on Kali Linux

By HackerBlogs

9 min read

FREE PENTEST TOOL

Strix on Kali Linux

Complete Installation, Configuration & Troubleshooting Report

Document Type: Technical Installation & Troubleshooting Report Operating System: Kali Linux Shell: Zsh Tool: Strix Multi-Agent Cybersecurity Penetration Testing Tool Initial Strix Version: 1.5.3 Final Strix Version: 1.6.0 LLM Provider: OpenRouter LLM Interface: LiteLLM Local LLM Runtime: Ollama Test Environment: Docker / OWASP Juice Shop Purpose: Complete reproducible installation and troubleshooting documentation

1. Introduction

This document records the complete process used to install, configure, troubleshoot, and verify Strix on Kali Linux.

The purpose of this report is to provide a self-contained technical reference so that another user can follow the installation without having to search through multiple tutorials or repeat the same mistakes.

The report documents both successful steps and problems encountered during the setup.

Each troubleshooting section follows this structure:

Problem → Error → Investigation → Cause → Solution → Verification

2. Final Architecture

The completed environment consists of the following components:

Kali Linux
│
├── Strix 1.6.0
│
├── LiteLLM 1.99.0
│
├── OpenRouter
│     └── openai/gpt-oss-120b
│
├── Ollama 0.33.2
│     └── CPU-only
│
└── Docker
      └── OWASP Juice Shop
            └── localhost:3001

The Docker/Juice Shop portion was used only as a controlled local testing environment. It is not required to use Strix against every target.

3. Prerequisites

Before starting the Strix installation, the following components are required or useful:

  • Kali Linux
  • Internet connection
  • Git
  • Python / pipx
  • Docker
  • An LLM API key
  • Zsh or another supported shell

Check Git:

git --version

Check Python:

python3 --version

Check pipx:

pipx --version

Check Docker:

docker --version

If Docker is installed but the daemon is not running:

sudo systemctl start docker

Verify:

docker info

Strix requires Docker for its security-testing sandbox. The official documentation also lists Docker and an LLM API key as prerequisites.

4. Phase 1 — Obtaining the Strix Source Code

None

4.1 Clone the Repository

The Strix source repository can be obtained using Git:

git clone https://github.com/usestrix/strix.git

Move into the repository:

cd strix

Verify the repository contents:

ls

The repository contains the Strix source code, configuration files, scripts, Docker-related files, and build configuration.

5. Understanding the Strix Installation Methods

There are two relevant approaches:

Method A — Official installer

The current Strix documentation provides:

curl -sSL https://strix.ai/install | bash

It also documents:

pipx install strix-agent

as an installation option.

Method B — Source repository

For development/source-based installation, clone the repository:

git clone https://github.com/usestrix/strix.git
cd strix

The repository contains a pyproject.toml defining the package as strix-agent and exposing the strix command.

For a normal user installation, Method A is simpler. For documenting/building from source, Method B is useful.

6. Phase 2 — Verify Strix Installation

After installation, verify the command:

which strix

Then:

strix --version

The initial installation used during this setup reported:

1.5.3

This confirmed that Strix was installed and accessible from the terminal.

7. Phase 3 — Updating Strix

The installed Strix version was later updated.

After updating, verify:

strix --version

Final version:

1.6.0

Therefore:

Initial version → 1.5.3
Final version   → 1.6.0

8. Phase 4 — Installing Ollama

Ollama was installed as a local LLM runtime.

After installation, verify it:

ollama --version

The installed version was:

ollama version 0.33.2

9. Starting and Checking Ollama

Check whether the Ollama service is running.

The local Ollama endpoint used was:

127.0.0.1:11434

A basic API check can be performed with:

curl http://127.0.0.1:11434/api/tags

If Ollama is not running, start the service:

sudo systemctl start ollama

Then check:

sudo systemctl status ollama

10. Ollama Hardware Limitation

During the setup, the system did not have a detected NVIDIA or AMD GPU.

Therefore, Ollama operated in:

CPU-only mode

This is important because local LLM inference can be considerably slower without GPU acceleration.

The system therefore used OpenRouter as the primary LLM provider for Strix.

Ollama remained installed as a local LLM option but was not the final primary provider configuration.

11. Phase 5 — Configure OpenRouter

OpenRouter was selected as the external LLM provider.

The API key was stored in:

export LLM_API_KEY="YOUR_API_KEY"

Replace YOUR_API_KEY with the actual key.

Security Warning

Never publish the real API key.

Do not put the complete key into:

  • GitHub
  • Screenshots
  • Public documentation
  • Videos
  • Chat messages
  • Public .env files

Use:

YOUR_API_KEY

when documenting the configuration.

12. Verify the API Key Safely

Instead of printing the complete API key, verify only part of it:

echo "${LLM_API_KEY:0:10}"

This confirms that the variable contains a value without displaying the complete secret.

13. Phase 6 — Test OpenRouter Independently

Before troubleshooting Strix, OpenRouter was tested directly.

Command:

curl https://openrouter.ai/api/v1/models \
  -H "Authorization: Bearer $LLM_API_KEY"

A successful response returned the available model list.

This confirmed:

Internet connectivity       ✓
OpenRouter reachable        ✓
API key accepted            ✓
Authentication working     ✓
Model API accessible        ✓

This was an important troubleshooting step because it separated provider/API problems from Strix problems.

14. Phase 7 — Initial Strix LLM Configuration

The first Strix model configuration used was:

export STRIX_LLM="openrouter/openai/gpt-oss-120b:free"

Verify it:

echo $STRIX_LLM

Output:

openrouter/openai/gpt-oss-120b:free

15. Problem 1 — LiteLLM.NotFoundError

After configuring the initial model, Strix produced a LiteLLM error similar to:

LiteLLM.NotFoundError

At this point, reinstalling Strix would not have been the correct first response.

The model/provider configuration needed to be investigated.

16. Investigation — Verify the Model Through OpenRouter

The OpenRouter API was queried directly:

curl https://openrouter.ai/api/v1/models \
  -H "Authorization: Bearer $LLM_API_KEY" |
  grep -o '"id":"openai/gpt-oss-120b"' |
  head

The response confirmed:

"id":"openai/gpt-oss-120b"

Therefore, the model identifier available through the API was:

openai/gpt-oss-120b

17. Resolution — Correct the Model Configuration

The original configuration:

openrouter/openai/gpt-oss-120b:free

was changed to:

openrouter/openai/gpt-oss-120b

Command:

export STRIX_LLM="openrouter/openai/gpt-oss-120b"

Verify:

echo $STRIX_LLM

Expected:

openrouter/openai/gpt-oss-120b

Lesson

Do not assume that a model name copied from an old tutorial is still the correct provider route.

Verify the provider's actual model ID.

18. Phase 8 — Install LiteLLM

LiteLLM was required for the LLM integration.

First check whether it was already available:

which litellm

The command did not find the executable.

Therefore, LiteLLM was installed with:

pipx install litellm

19. Problem 2 — litellm Dependency Error

After installation:

litellm --version

was executed.

The command produced:

ModuleNotFoundError: No module named 'websockets'

This indicated that LiteLLM was installed but one of its required dependencies was missing.

20. Resolution — Install LiteLLM Proxy Dependencies

The required dependencies were injected into the LiteLLM environment:

pipx inject litellm "litellm[proxy]"

When a forced refresh was required:

pipx inject --force litellm "litellm[proxy]"

After installation, verify:

litellm --version

Final working version:

1.99.0

21. Why pipx inject Was Used

pipx creates isolated environments for Python applications.

Instead of installing random Python packages globally, the missing dependencies were added specifically to the LiteLLM environment:

pipx inject litellm "litellm[proxy]"

This kept the dependency change associated with LiteLLM.

22. Phase 9 — Make the Strix Model Configuration Persistent

The following command:

export STRIX_LLM="openrouter/openai/gpt-oss-120b"

only affects the current shell session.

To make the configuration available when opening a new Zsh terminal, it was added to:

~/.zshrc

Command:

echo 'export STRIX_LLM="openrouter/openai/gpt-oss-120b"' >> ~/.zshrc

Reload the configuration:

source ~/.zshrc

Verify:

echo $STRIX_LLM

Expected:

openrouter/openai/gpt-oss-120b

Important

Do not append the same line repeatedly.

If the line already exists in ~/.zshrc, leave it as it is.

23. API Key Persistence

If the API key is also intended to be available in every new terminal, it can be exported through the shell environment.

Example:

export LLM_API_KEY="YOUR_API_KEY"

For security, avoid committing shell configuration containing real secrets to public repositories.

24. Phase 10 — Verify the Strix CLI

Run:

strix --help

The available options include:

-t / --target
--target-list
--instruction
--instruction-file
-n / --non-interactive
-m / --scan-mode
--scope-mode
--max-budget
--max-turns
--resume

Available scan modes include:

quick
standard
deep

This confirmed that the Strix CLI was functioning correctly.

25. Phase 11 — Docker Verification

Docker was required by Strix for its sandbox environment.

Check Docker:

docker --version

Final Docker version:

Docker 28.5.2+dfsg4

Check Docker Compose:

docker compose version

Final version:

Docker Compose 2.40.3-3

Check the Docker daemon:

docker info

If Docker is functioning, the command should return Docker system information rather than a daemon connection error.

None

26. Phase 12 — Local Testing Environment

A local OWASP Juice Shop instance was created for testing Strix.

This was not part of the Strix installation itself.

It was only a safe, controlled target for testing the installed tool.

Start Juice Shop:

docker run -d \
  --name juice-shop \
  -p 3001:3000 \
  bkimminich/juice-shop

Verify:

docker ps

The application was then available at:

http://localhost:3001

27. Juice Shop Container Already Exists

If Docker reports that the container already exists, do not create another container.

Start the existing container:

docker start juice-shop

Verify:

docker ps

This is preferable to repeatedly running docker run.

28. Phase 13 — First Strix Run

Start Strix:

strix

For the local Juice Shop test environment, the target was:

http://localhost:3001

This provided a controlled environment for verifying the complete Strix → LLM → Docker workflow.

29. Troubleshooting Methodology

When Strix fails, the following order should be used.

Step 1 — Check Strix

strix --version

Expected:

1.6.0

Step 2 — Check the model

echo $STRIX_LLM

Expected:

openrouter/openai/gpt-oss-120b

Step 3 — Check the API key

echo "${LLM_API_KEY:0:10}"

Do not print the complete key.

Step 4 — Check OpenRouter

curl https://openrouter.ai/api/v1/models \
  -H "Authorization: Bearer $LLM_API_KEY"

Step 5 — Check LiteLLM

litellm --version

Expected:

1.99.0

Step 6 — Check Docker

docker info

Step 7 — Check the local test target

docker ps

Step 8 — Run Strix

strix

This order prevents unnecessary reinstalls.

30. Complete Problem-and-Solution Record

ProblemWhat HappenedSolutionStrix initially reported 1.5.3Older installed versionUpdated to 1.6.0Model configuration failedInitial model route produced LiteLLM.NotFoundErrorVerified model through OpenRouter APIIncorrect model routeopenrouter/openai/gpt-oss-120b:free was problematicChanged to openrouter/openai/gpt-oss-120blitellm unavailableLiteLLM was not installedpipx install litellmwebsockets missingLiteLLM dependency problempipx inject litellm "litellm[proxy]"Dependency environment needed refreshExisting pipx environmentpipx inject --force litellm "litellm[proxy]"Model variable was temporaryexport only affects current shellAdded STRIX_LLM to ~/.zshrcOllama had no GPUNo NVIDIA/AMD GPU detectedContinued with CPU-only Ollama / OpenRouterJuice Shop container already existedDocker container name conflictdocker start juice-shop

31. Final Environment Verification

Run the following commands.

Strix

strix --version

Expected:

1.6.0

LiteLLM

litellm --version

Expected:

1.99.0

Ollama

ollama --version

Expected:

ollama version 0.33.2

Strix Model

echo $STRIX_LLM

Expected:

openrouter/openai/gpt-oss-120b

OpenRouter

curl https://openrouter.ai/api/v1/models \
  -H "Authorization: Bearer $LLM_API_KEY"

Docker

docker info

Local Test Target

docker ps

32. Final Configuration

The final working configuration was:

Strix:
    Version: 1.6.0
LLM:
    Provider: OpenRouter
    Model: openai/gpt-oss-120b
LiteLLM:
    Version: 1.99.0
Ollama:
    Version: 0.33.2
    Mode: CPU-only
Docker:
    Version: 28.5.2+dfsg4
Docker Compose:
    Version: 2.40.3-3
Shell:
    Zsh
Persistent model configuration:
    ~/.zshrc
Testing target:
    OWASP Juice Shop
    http://localhost:3001

33. Security and Operational Notes

API Keys

Never expose the real:

LLM_API_KEY

Use placeholders when sharing configuration:

YOUR_API_KEY

Authorized Testing

Strix should only be used against:

  • Your own applications
  • Authorized systems
  • CTF/lab environments
  • Systems for which explicit permission has been provided

The local Juice Shop instance was used specifically to provide a controlled testing target.

34. Important Distinction: Strix vs. Juice Shop

Juice Shop was not installed because Strix requires Juice Shop.

The relationship is:

Strix
  ↓
Security testing tool
Juice Shop
  ↓
Temporary vulnerable application
  ↓
Local test target

Therefore, someone installing Strix for normal use does not necessarily need to install Juice Shop.

Juice Shop was included in this setup only to test Strix safely against a deliberately vulnerable application.

35. Post-Installation Startup Procedure

After everything has already been installed and configured, the startup process is much shorter.

If you only want to start Strix

Open a new Kali terminal and run:

source ~/.zshrc

Then:

strix

That is all that is required for Strix itself.

36. If Using the Local Juice Shop Test Environment

If you want to continue using the local Juice Shop test target, first start the existing container:

docker start juice-shop

Check:

docker ps

Then start Strix:

strix

Target:

http://localhost:3001

Therefore, the complete local testing startup sequence is:

source ~/.zshrc
docker start juice-shop
strix

Then use:

http://localhost:3001

as the authorized local testing target.

37. Final Daily Workflow

After the installation is complete, there is no need to reinstall everything every time.

Strix only:

source ~/.zshrc
strix

Strix + local Juice Shop:

source ~/.zshrc
docker start juice-shop
strix

The following should not be repeated every time:

git clone
Strix installation
LiteLLM installation
Ollama installation
API key generation
Model configuration
Juice Shop creation

Those are installation/configuration tasks.

The final daily workflow is simply:

Load configuration
      ↓
Start test target (only if using Juice Shop)
      ↓
Start Strix
      ↓
Enter authorized target

38. Conclusion

The Strix installation was completed through several stages rather than a single command.

The major troubleshooting points were:

  1. Strix was initially installed at version 1.5.3 and later updated to 1.6.0.
  2. Ollama was installed and verified, but the system operated without supported GPU acceleration.
  3. OpenRouter was configured as the primary external LLM provider.
  4. The initial openrouter/openai/gpt-oss-120b:free configuration produced a LiteLLM NotFoundError.
  5. The OpenRouter API was queried directly to verify the correct model identifier.
  6. The model configuration was changed to: openrouter/openai/gpt-oss-120b
  7. LiteLLM was installed using pipx.
  8. A missing websockets dependency was identified and corrected using LiteLLM's proxy dependencies.
  9. The Strix model configuration was made persistent through ~/.zshrc.
  10. Docker was verified and a local OWASP Juice Shop instance was used only as a controlled test target.
  11. The final startup process was reduced to a few commands.

The main troubleshooting principle from this installation is:

Do not reinstall the entire environment when one component fails. Identify the failing layer, test it independently, fix that layer, and verify it before continuing.

PREPARE BY HACKER BLOGS AS GHULAM AHMAD