feat: Claude Code CLI (subscription) execution lane — run Strix on a Claude Pro/Max login, no metered API key

[Raman-kr1]

Problem / motivation

Strix currently requires a metered LLM_API_KEY. For users who already pay for a
Claude Pro/Max subscription, every scan bills the API separately, which makes routine
/ iterative use expensive. There's no way to run Strix on an existing Claude
subscription.

Proposed feature

Add a second, opt-in execution lane selected by a claude-cli/ model prefix:

STRIX_LLM=claude-cli/claude-opus-5   # runs on ~/.claude subscription login, no API key

A Claude Pro/Max subscription has no raw model endpoint — it's reachable only through
the claude CLI / claude-agent-sdk, which is a full agent with its own loop. So it
can't be an OpenAI-Agents Model subclass (unlike the existing ChatGPT/Codex lane).
Instead, Claude Code becomes the agent and Strix supplies its tools over MCP,
reusing the existing Docker sandbox + Caido proxy so real pentest capability is
preserved.

Design (high level)

• Dispatch at the Runner.run_streamed call site: claude-cli/ → a ClaudeCliStream
  driving a claude_agent_sdk.ClaudeSDKClient; everything above/below _run_cycle
  (coordinator, budget, ReportState) is reused unchanged.
• Strix's existing ~30 FunctionTools are auto-exposed as mcp__strix__* via one
  adapter (reuses .params_json_schema + .on_invoke_tool), so notes/proxy/reporting
  AND the whole agents_graph multi-agent family work for free.
• A small hand-written MCP bridge exposes sandbox shell/fs tools via session.exec.
• Auth: no ANTHROPIC_API_KEY (its absence is what selects the subscription login);
  fail fast if it's set.

Why opt-in / ToS note

This automates a subscription for unattended use, which is a grey area vs. the metered
API. Kept strictly opt-in behind the explicit claude-cli/ prefix, with a one-time
notice. Flagging this openly for maintainer input before I open a PR — happy to adjust
scope (e.g. gate behind an env flag, docs-only warning, etc.).

Status

Working prototype on my fork: full multi-agent graph runs end-to-end on a subscription
with no API key — a code scan spawned 5 concurrent agents and produced 3 PoC-verified
IDOR findings. Unit tests pass; ruff clean.

Question for maintainers

Is a subscription lane something you'd accept in-tree given the ToS consideration? If
so, any constraints on how it should be gated/documented before I open the PR?

[Vitanakpapa]

#1150