Read the whole setupFirst scan before lunch.
Drop your email and the rest opens: the install, the model and budget I run, the three scan modes and when each fits, the CI job that scopes itself to a pull request, and the two ways it goes wrong.
One email. No follow-up unless I ship something that fits.
WHAT YOU NEED- Docker, running. The first scan pulls the sandbox image
- An LLM key from any provider LiteLLM speaks: OpenAI, Anthropic, Google, OpenRouter, a local model
- A target you own. A local folder, a repo you control, a staging URL, or an OpenAPI spec. Written permission if it is not yours
- Nothing else. The toolkit, the browser and the proxy all live in the sandbox image
INSTALLOne command, two variables, one scan
The installer puts the CLI on your path. Configuration is two environment variables, and Strix remembers them in ~/.strix/cli-config.json so you set them once. Start on a local folder rather than a live URL: the feedback is faster and the blast radius is nothing.
The install
terminala target you own
$ curl -sSL https://strix.ai/install | bash $ export STRIX_LLM="anthropic/claude-sonnet-4-6" $ export LLM_API_KEY="sk-ant-..." $ strix --target ./my-app --scan-mode quick --max-budget 5 → pulls the sandbox image once, then writes to strix_runs/<run-name>
Every run writes to disk as it goes. strix view opens the last one in a local dashboard, bound to 127.0.0.1, with the agent map and the findings. Nothing leaves your machine.
Prove itRun that first scan on a folder you know has a weakness, an old branch with a hardcoded key or an unparameterised query. If it comes back with the exploit and not just the observation, the sandbox and your model are both working. An empty result on a clean folder tells you nothing yet.
CONFIGUREFive settings, one of them mandatory
Configuration is environment variables, or the same keys in a JSON config file you can commit without secrets. The budget flag is the one I never omit, because an uncapped deep scan with sub-agents is an open tab at your model provider.
~/.strix/cli-config.jsonmy values
{ "env": { "STRIX_LLM": "anthropic/claude-sonnet-4-6", "LLM_API_KEY": "sk-ant-...", "STRIX_REASONING_EFFORT": "high", "STRIX_TELEMETRY": "0" } }
| Setting | Default | Why I change it |
|---|
| --max-budget | none, uncapped | The single most important flag. In headless mode it stops the scan cleanly at the cap and still writes the report, with sub-agents halted at 90 percent so the root can finish. Interactive mode pauses instead, and any message resumes with the cap extended. |
| --scan-mode | deep | Deep is right when you are sitting there watching. Quick is right in CI, where it scopes itself to the files a pull request changed and reasoning effort drops to medium on its own. |
| STRIX_TELEMETRY | 1 | PostHog, Scarf and OpenTelemetry are on out of the box. On client code that is a conversation you do not want to have later. Local run logs are unaffected. |
| STRIX_DEDUPE_MODEL | falls back to STRIX_LLM | Deciding whether a finding duplicates another is a cheap classification job. Point it at a small model and the main one stays on the actual testing. |
| --max-turns | 500 | Per agent, not per run. Fine on a real assessment, generous for a smoke test. Lower it with the budget when you just want to know the pipeline works. |
The cap is approximateThe budget is checked after each model response, so calls already in flight can overshoot it slightly, most visibly with several sub-agents running at once. Cost is estimated from token usage and provider pricing. Treat the number as a brake, not a contract.
DAILY DRIVINGFour targets, in rising order of nerve
Targets stack: give it the source and the running app together and it correlates the two. Credentials and focus areas go in --instruction, which is where a grey-box test starts. Everything below is a target you own.
.github/workflows/strix.ymlthe part that matters
- uses: actions/checkout@v6 with: { fetch-depth: 0 } - run: curl -sSL https://strix.ai/install | bash - run: strix -n -t ./ --scan-mode quick --max-budget 3 env: { STRIX_LLM: ..., LLM_API_KEY: ... }
- The codebase first.
--target ./app or a repo URL. Cheapest, safest, and it finds the class of bug that never reaches a crawler. - Then the API contract. Point it at an OpenAPI file or a Postman export plus the live base URL, and it tests declared endpoints instead of guessing them.
- Then the running app. A staging URL, black box. Add credentials through
--instruction to get behind the login. - Then every pull request. Headless, quick mode, exits non-zero on a finding. This is the one that changes how a team ships.
The full history in the checkout is what lets quick mode diff against the base branch. Without it the scope logic has nothing to compare, and you pay for a full scan on every pull request.
WHEN IT DRIFTSTwo failures, both about scope
The scan costs more than expected
Deep mode with sub-agents and no cap. Set --max-budget, drop to quick for routine runs, and move deduplication to a smaller model. Check --max-turns too, since 500 applies to each agent.
It reports things that are not really bugs
Usually an agent testing something outside what you meant. Tell it the scope in --instruction or an instruction file: which hosts, which flows, what is out of bounds. Vague scope is what produces noise here, not the model.
Sharing a runstrix view prints a tokened link that grants access to that run, which includes working exploits against your app. Treat that link like the exploits it contains, and do not paste it into a group chat.
THE SHAPE OF ITWhere everything lives
~/.strix/cli-config.jsonthe model, the key, the defaults you set once ~/.strix/mcp-servers.jsonyour own MCP servers, exposed to the agents strix_runs/<run-name>/findings, report and the full run record strix_runs/<run-name>/events.jsonllocal telemetry, written whether or not you export it skills/nine agent skills, installed with `npx skills add usestrix/strix`
The run folders are the artefact worth keeping: each one holds the proof that a bug existed and the date you knew about it. Treat them as sensitive, because that is exactly what they are.
That is the whole setupOne install, two variables, a budget you always set, and a quick scan on every pull request. The question of whether the thing you just shipped is exploitable stops waiting for a calendar slot.
Open on GitHub →
↑ Unlocks the moment you submit the form above.
