fix(warmup): import scan deps synchronously to avoid agents-SDK import race

[thehashes]

Summary

start_import_warmup() pre-imports the heavy scan dependencies on a background
daemon thread to overlap the cost with CLI startup I/O. This races the main
thread and crashes the scan at bootstrap on some hosts.

The warm-up imports strix.core.runner, which pulls in the agents SDK, whose
package graph has internal circular imports. CPython breaks import cycles by
exposing a partially initialized module, and that partial state is visible
across threads. When the warm-up thread and the main thread (warm_up_llm
imports agents.model_settings / agents.models.interface) import that graph
concurrently, they intermittently observe each other's partial agents package
and crash.

Symptom

Every scan aborts during _bootstrap_scan -> warm_up_llm with one of:

KeyError: 'agents'

ImportError: cannot import name 'AgentOutputSchemaBase' from partially
initialized module 'agents.agent_output' (most likely due to a circular import)

This reproduces reliably on some environments (observed consistently on WSL2 /
Kali, Python 3.12 and 3.13, with the current pinned openai-agents 0.19.x). The
per-module import lock does not prevent it, because the import system
deliberately hands out partial modules mid-cycle to avoid deadlock.

Fix

Import the warm-up modules synchronously on the calling thread instead of on a
background daemon thread. Warm-up only runs on the scan path, which eagerly
imports all of these modules anyway, so importing here adds no net work; it only
removes the unsound concurrent-import overlap.

• start_import_warmup() now performs a run-once synchronous import guarded by
  the existing lock and returns None (its Thread return value was never
  used).
• Module and function docstrings updated to explain why the background thread
  was unsafe.

Testing

• Before: strix -n -t <target> ... aborts at bootstrap with KeyError: 'agents'.
• After: the same command starts cleanly, connects configured MCP servers, and
  runs to completion.
• start_import_warmup() has no other callers that use its return value, and
  there is no existing test that depends on the daemon-thread behaviour.

[greptile-apps]

Greptile Summary

The PR makes scan dependency warmup synchronous and run-once to prevent concurrent imports from exposing partially initialized Agents SDK modules.

• Replaces the daemon thread state with a _warmed flag protected by the existing lock.
• Performs heavy imports directly on the caller and changes the helper return type to None.
• Expands documentation explaining the import race and synchronous behavior.

Confidence Score: 4/5

The PR appears safe to merge, with a non-blocking cold-start regression for help, version, update, and setup invocations that should be addressed by moving synchronous warmup onto the confirmed scan path.

The import-race fix is coherent, but synchronous _warm() currently runs before argument parsing, forcing lightweight non-scan commands to wait for all heavy scan dependencies.

Files Needing Attention: strix/llm/warmup.py and strix/interface/main.py

Important Files Changed

Filename	Overview
strix/llm/warmup.py	The synchronous import removes the described cross-thread race, but the existing pre-parse call site now imposes heavy scan imports on several non-scan CLI paths.

Prompt To Fix All With AI

### Issue 1
strix/llm/warmup.py:69
**Synchronous imports delay non-scan commands**

`_warm(modules)` now blocks the caller, but the sole call occurs before argument parsing determines whether a scan will run. Consequently, cold `--help`, `--version`, `--update`, and interactive setup invocations wait for the full heavy scan dependency graph before responding; move the synchronous warmup onto the confirmed scan path.

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

_{Reviews (1): Last reviewed commit: "fix(warmup): import scan deps synchronou..." | Re-trigger Greptile}