* fix: --config flag now fully overrides ~/.strix/cli-config.json (fixes#377)
Previously, env vars applied from the default config at module import time
were not cleared when --config was later processed, causing settings from
~/.strix/cli-config.json to leak into runs that specified a custom config.
Track which vars were applied by the initial default-config load in
Config._applied_from_default. In apply_config_override, clear those vars
before applying the custom config so only the custom file's settings take effect.
* Add config override regression test
* Make config override test setup explicit
---------
Co-authored-by: octo-patch <octo-patch@github.com>
Co-authored-by: bearsyankees <bearsyankees@gmail.com>
* fix: wrap acompletion in asyncio.wait_for to prevent indefinite hangs
litellm's timeout parameter doesn't always propagate to the underlying
httpx transport for Bedrock converse streaming. When Bedrock accepts the
TCP connection but never starts streaming chunks, the acompletion call
hangs indefinitely with all connections in CLOSED state.
This wraps the acompletion call in asyncio.wait_for() using the
configured LLM_TIMEOUT (default 300s). TimeoutError is already retryable
via _should_retry (status_code=None), so the retry loop handles it.
Diagnosed via faulthandler thread dump showing the main asyncio event
loop blocked in selectors.select() with no pending callbacks.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
* fix: add per-chunk timeout to streaming loop
Addresses review feedback: the initial asyncio.wait_for only guards the
acompletion call. If Bedrock returns headers but stalls mid-stream, the
async for loop could still hang indefinitely.
Replaces async for with explicit __anext__ calls wrapped in
asyncio.wait_for, using the same configured timeout. Mid-stream stalls
now raise TimeoutError and trigger the existing retry logic.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
---------
Co-authored-by: Sean Turner <sean.turner@zerohash.com>
Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>
Models occasionally output text-only narration ("Planning the
assessment...") without a tool call, which halts the interactive agent
loop since the system interprets no-tool-call as "waiting for user
input." Rewrite both interactive and autonomous prompt sections to make
the tool-call requirement absolute with explicit warnings about the
system halt consequence.
- Change default model from gpt-5 to gpt-5.4 across docs, tests, and examples
- Remove Strix Router references from docs, quickstart, overview, and README
- Delete models.mdx (Strix Router page) and its nav entry
- Simplify install script to suggest openai/ prefix directly
- Keep strix/ model routing support intact in code
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Re-architects the agent loop to support interactive (chat-like) mode
where text-only responses pause execution and wait for user input,
while tool-call responses continue looping autonomously.
- Add `interactive` flag to LLMConfig (default False, no regression)
- Add configurable `waiting_timeout` to AgentState (0 = disabled)
- _process_iteration returns None for text-only → agent_loop pauses
- Conditional system prompt: interactive allows natural text responses
- Skip <meta>Continue the task.</meta> injection in interactive mode
- Sub-agents inherit interactive from parent (300s auto-resume timeout)
- Root interactive agents wait indefinitely for user input (timeout=0)
- TUI sets interactive=True; CLI unchanged (non_interactive=True)
The perplexity API key check in strix/tools/__init__.py used
Config.get() which only checks os.environ. At import time, the
config file (~/.strix/cli-config.json) hasn't been applied to
env vars yet, so the check always returned False.
Replace with _has_perplexity_api() that checks os.environ first
(fast path for SaaS/env var), then falls back to Config.load()
which reads the config file directly.
Users can now access the Caido web UI from their browser to inspect traffic,
replay requests, and perform manual testing alongside the automated scan.
- Map Caido port (48080) to a random host port in DockerRuntime
- Add caido_port to SandboxInfo and track across container lifecycle
- Display Caido URL in TUI sidebar stats panel with selectable text
- Bind Caido to 0.0.0.0 in entrypoint (requires image rebuild)
- Bump sandbox image to 0.1.12
- Restore discord link in exit screen
The badge image URL used invite code which is expired,
causing the badge to render 'Invalid invite' instead of the server info.
Updated to use the vanity URL which resolves correctly.
Fixes#313
Chethas Dileep