feat: add STRIX_DISABLE_FIX_AGENTS to skip dedicated fix subagents

[0xfelixli]

What

Adds an opt-in env flag, STRIX_DISABLE_FIX_AGENTS (default false), that tells the root coordinator not to spawn dedicated fix/remediation subagents.

Why

On large scans the coordinator routinely spawns a separate "… Fixing Agent" per confirmed finding. For cost-conscious runs that just want findings + reports, those extra agents mostly burn tokens and concurrency: remediation is already required and captured inline in each report's remediation_steps.

How

• New AgentSettings.disable_fix_agents (STRIX_DISABLE_FIX_AGENTS), re-exported from strix.config like the other settings sub-models.
• When set, a short directive is appended to the root agent's prompt only, overriding the "Fix agent provides remediation" delegation step.
• Off by default — no behavior change for existing users. The shipped skill file and all child prompts are untouched.

Prompt-level directive (soft constraint), not a tool-level block; happy to add hard enforcement at the spawn tool if preferred.

🤖 Generated with Claude Code

[greptile-apps]

Greptile Summary

This PR introduces an opt-in STRIX_DISABLE_FIX_AGENTS environment flag that appends a short markdown directive to the root coordinator's prompt, instructing it to skip spawning dedicated fix/remediation subagents. The setting is off by default, so existing users see no behavior change.

• A new AgentSettings pydantic-settings sub-model is added to settings.py, exported from strix/config/__init__.py, and composed into Settings.agents — fully consistent with the existing LlmSettings, RuntimeSettings, etc. pattern.
• In render_system_prompt, the directive is appended to skill_content["root_agent"] before the get_skill lambda is closed over and before **skill_content is spread into the Jinja render, so both template access paths see the modified content correctly.
• The feature is a soft/prompt-level constraint (as noted in the PR description); hard enforcement at the tool-spawn level could be added later if needed.

Confidence Score: 4/5

Safe to merge — the flag is off by default and all three changed files make purely additive changes with no impact on existing behaviour.

The implementation is small, focused, and consistent with existing patterns. The one note-worthy edge case — load_settings() being called inside render_system_prompt's exception-swallowing block — could obscure config errors in the rare scenario where settings are loaded for the first time on this path, but the practical risk is low given memoisation.

strix/agents/prompt.py — the new load_settings() call sits inside the broad exception handler; worth a quick look if the flag ever appears not to take effect.

Important Files Changed

Filename	Overview
strix/config/settings.py	Adds AgentSettings sub-model with a disable_fix_agents bool field wired to STRIX_DISABLE_FIX_AGENTS; consistent with every other sub-model in the file.
strix/config/init.py	Re-exports AgentSettings alongside the other public sub-models and updates the module docstring; purely additive, no issues.
strix/agents/prompt.py	Introduces the directive constant and conditionally appends it to skill_content["root_agent"]. The modification happens before the get_skill lambda is closed over, so both access paths are consistent. load_settings() is called inside the function's broad try/except, meaning a first-call failure would be silently swallowed.

Prompt To Fix All With AI

Fix the following 1 code review issue. Work through them one at a time, proposing concise fixes.

---

### Issue 1 of 1
strix/agents/prompt.py:99-104
**Settings failure silently disables the flag**

`load_settings()` is called here for the first time on this code path inside the function's broad `try/except Exception` block. If settings initialisation raises on that first call (e.g. a pydantic `ValidationError` from an unexpected env value), the exception is caught, logged only as `"render_system_prompt failed; returning empty prompt"`, and the root agent gets an empty system prompt — with no indication that `STRIX_DISABLE_FIX_AGENTS` was involved. In practice `load_settings()` is memoized and is almost certainly already warm before this point, but calling it outside the try block (or at least asserting `_cached is not None` before entering it) would make failure attribution clearer.

_{Reviews (1): Last reviewed commit: "feat: add STRIX_DISABLE_FIX_AGENTS to sk..." | Re-trigger Greptile}

[greptile-apps]

Settings failure silently disables the flag

load_settings() is called here for the first time on this code path inside the function's broad try/except Exception block. If settings initialisation raises on that first call (e.g. a pydantic ValidationError from an unexpected env value), the exception is caught, logged only as "render_system_prompt failed; returning empty prompt", and the root agent gets an empty system prompt — with no indication that STRIX_DISABLE_FIX_AGENTS was involved. In practice load_settings() is memoized and is almost certainly already warm before this point, but calling it outside the try block (or at least asserting _cached is not None before entering it) would make failure attribution clearer.

Prompt To Fix With AI

This is a comment left during a code review.
Path: strix/agents/prompt.py
Line: 99-104

Comment:
**Settings failure silently disables the flag**

`load_settings()` is called here for the first time on this code path inside the function's broad `try/except Exception` block. If settings initialisation raises on that first call (e.g. a pydantic `ValidationError` from an unexpected env value), the exception is caught, logged only as `"render_system_prompt failed; returning empty prompt"`, and the root agent gets an empty system prompt — with no indication that `STRIX_DISABLE_FIX_AGENTS` was involved. In practice `load_settings()` is memoized and is almost certainly already warm before this point, but calling it outside the try block (or at least asserting `_cached is not None` before entering it) would make failure attribution clearer.

How can I resolve this? If you propose a fix, please make it concise.