Problem
Strix currently owns both its security-testing capabilities and its model runtime. Users must configure a separate LLM provider and API key even when they already use an authenticated coding agent such as Codex or Claude Code.
This couples Strix’s sandbox, proxy, security knowledge, reporting, model credentials, sessions, and orchestration into one runtime.
Proposal
Add an experimental agent-native runtime that separates reasoning from Strix’s security capabilities:
- Codex, Claude Code, or another coding agent performs all LLM reasoning through its existing authenticated runtime.
- A portable
strix-security skill defines the assessment workflow, scope rules, validation requirements, and reporting quality bar.
- A local
strix-mcp server exposes Strix’s sandbox, Caido proxy, security knowledge, findings, and report lifecycle.
- Strix does not require or call a model-provider API in this mode.
- The existing CLI remains usable:
strix --agent codex --target ./app
strix --agent claude --target ./app
The legacy provider-backed runtime should remain available during evaluation.
Initial proof-of-concept scope
The first implementation should provide:
- Runtime selection through --agent auto|codex|claude|legacy
- Ephemeral MCP configuration when launching Codex or Claude Code
- A separately installable portable skill
- Target initialization and scope preservation
- Local directories, repositories, URLs, domains, IPs, and combined targets
- Quick, standard, and deep scan modes
- Full and diff-based source scope
- Docker sandbox command execution
- Caido request inspection, replay, sitemap, and scope management
- On-demand loading of existing Strix security knowledge
- Model-free vulnerability creation and deduplication
- Existing Markdown, JSON, CSV, and SARIF artifacts
- Finish, stop, cleanup, and report-state resume operations
- Packaging and installation helpers
- Unit tests and detailed architecture documentation
Important status
This should initially be treated as a skeleton and proof of concept, not production-ready parity with the existing Strix runtime.
The proof of concept is intended to validate the architecture and establish stable boundaries between:
- host-agent reasoning and orchestration;
- Strix security execution and persistence.
Known limitations to address
The initial version may not include:
- Persisted Codex or Claude Code conversation history
- Full AgentCoordinator and subagent graph parity
- Legacy TUI and live progress parity
- Host-agent token and cost accounting
- Background command sessions or stdin streaming
- Semantic model-based deduplication
- Legacy Perplexity search
- Built-in adapters for coding agents other than Codex and Claude Code
- Cross-platform validation
- Recovery for abruptly terminated MCP processes
- Complete Docker-backed end-to-end coverage
Acceptance criteria for the proof of concept
Follow-up direction
If the proof of concept is accepted, follow-up work should focus on:
- a shared runtime abstraction for legacy and MCP orchestration;
- background process and stdin support;
- host-session persistence and resume semantics;
- semantic deduplication without hidden Strix model calls;
- structured progress and observability;
- additional coding-agent adapters;
- Docker-backed end-to-end tests;
- security threat modeling and production hardening.
Problem
Strix currently owns both its security-testing capabilities and its model runtime. Users must configure a separate LLM provider and API key even when they already use an authenticated coding agent such as Codex or Claude Code.
This couples Strix’s sandbox, proxy, security knowledge, reporting, model credentials, sessions, and orchestration into one runtime.
Proposal
Add an experimental agent-native runtime that separates reasoning from Strix’s security capabilities:
strix-securityskill defines the assessment workflow, scope rules, validation requirements, and reporting quality bar.strix-mcpserver exposes Strix’s sandbox, Caido proxy, security knowledge, findings, and report lifecycle.The legacy provider-backed runtime should remain available during evaluation.
Initial proof-of-concept scope
The first implementation should provide:
Important status
This should initially be treated as a skeleton and proof of concept, not production-ready parity with the existing Strix runtime.
The proof of concept is intended to validate the architecture and establish stable boundaries between:
Known limitations to address
The initial version may not include:
Acceptance criteria for the proof of concept
Follow-up direction
If the proof of concept is accepted, follow-up work should focus on: