strix-agent 1.0.4 crashes after producing a valid report, tripping the fail-closed gate; upgrade blocked by a cryptography CVE pin conflict

[seonghobae]

Problem

The required strix check is failing on multiple open PRs in contextual-orchestrator with the same pattern: Strix completes its scan, prints a full Penetration test completed report to the console (including a real vulnerability list), and then the process itself exits non-zero (exit code 2, or 124/timeout on one occasion) before its report artifact is durably written. scripts/ci/strix_quick_gate.sh then correctly and conservatively fails closed ("No Strix vulnerability report artifact was produced; log-only severity markers are incomplete evidence") -- that fail-closed behavior is working as designed (see #891) and should not be weakened. The bug is upstream of the gate script.

Evidence

Reproduced identically across 4 independent PRs on contextual-orchestrator (all using nvidia_nim/nvidia/nemotron-3-super-120b-a12b, sometimes falling back to nvidia_nim/nvidia/llama-3.3-nemotron-super-49b-v1.5):

PR	Run	Symptom
#136	job 94300522345	Vulnerabilities LOW: 1 printed, then exit code 2
#141	job 94307175551	Vulnerabilities CRITICAL: 1 printed, then exit code 2
#144	job 94310232826	Vulnerabilities CRITICAL: 1 printed (on fallback model), then exit code 2
#137	job 94301902010	Final attempt exits 124 (timeout) after ~15 min, following two prior exit-1 attempts

Root cause hypothesis

requirements-strix-ci.txt pins strix-agent==1.0.4. The upstream project's own release notes (https://github.com/usestrix/strix/releases) list two fixes directly matching this symptom, both shipped after 1.0.4:

• v1.1.0: "Atomic CSV/MD writes to prevent corruption on crash" -- matches a report that was generated (visible in the console log) but not durably persisted as an artifact.
• v1.4.0: "Quit after scan instead of hosting local viewer" -- prior versions apparently lingered/hosted a local viewer process after completing a scan; in a non-interactive CI container with a process timeout, that's a very plausible source of the hangs/non-zero exits observed here (including the exit 124 case in PR Allow central fix scheduler to scan target repositories #137, and the AsyncExitStack-style crash-after-print shape in the others).

Latest available is 1.5.3; none of 1.4.0 through 1.5.3 have relaxed the fix.

Why this isn't a one-line bump

strix-agent (every version 1.4.0 through the latest 1.5.3) requires cryptography<49,>=48.0.1. This repo's requirements-strix-ci.txt deliberately pins cryptography==50.0.0 (commit 7616fd80, "fix(security): refresh vulnerable Strix lock snapshot") to fix CVE-2026-39892 (a Bleichenbacher-style timing oracle in pkcs7_decrypt_der/pkcs7_decrypt_pem/pkcs7_decrypt_smime, present from cryptography 44.0.0 through <50.0.0, fixed in 50.0.0). uv pip compile --generate-hashes ... (the documented regeneration command in CLAUDE.md) correctly refuses to resolve strix-agent==1.5.3 + cryptography==50.0.0 together -- it is a genuine, currently-unresolved upstream constraint conflict, not a lockfile-generation mistake. I did not force an override past a declared dependency constraint without evidence that combination actually works at runtime.

Suggested next steps (not attempted here, needs a decision)

1. Open an upstream issue/PR against usestrix/strix asking them to relax the cryptography<49 upper bound (cryptography 48->50 does not appear to remove any API strix-agent would plausibly use, based on the changelog -- but this needs upstream confirmation, not a guess from this side).
2. As a stopgap, test whether strix-agent==1.5.3 actually runs correctly against cryptography==50.0.0 despite its declared range (an explicit uv pip compile --override + a real scan run, not just an install), and accept that combination deliberately with a comment explaining the override.
3. Alternative: if neither is viable soon, consider whether STRIX_TRANSIENT_RETRY_PER_MODEL should be raised as an interim mitigation -- note this only helps if the crash is retried, and none of is_transient_same_model_retry_error()'s four existing categories (rate limit, LLM API connection, LLM service unavailable, midstream fallback) currently match this failure signature, so the classifier would need a new, narrowly-scoped category first (e.g. "process exited non-zero after a complete Penetration test completed block was observed in the log") -- I'm flagging this option rather than implementing it, since it touches the fail-closed security logic itself and deserves review, not a drive-by change.

Impact

This is the org-wide central required workflow (ContextualWisdomLab/.github's strix.yml + scripts/ci/strix_quick_gate.sh), so it affects every repo with the Strix ruleset, not just contextual-orchestrator.

[seonghobae]

Fresh cross-repository reproduction from ContextualWisdomLab/scopeweave#496 materially strengthens this failure class and exposes one additional acceptance requirement. Exact protected-base/head pair is develop@44e7903cf8891c65410f7fc6ca5144de3fdb5185 -> 471467051114c96892d47c2776eb6e25921d1a34; Strix run 31990202058, job/check 95272246572, failed after ~43 minutes with exit 2. The uploaded strix-reports artifact does exist (artifact_id=9275984657, digest sha256:aeab9c4179d44f0c3611f11dc62c2db44dc602ceb9caf426d1e0bff939d11280) and contains a completed penetration_test_report.md, vulnerabilities.json/csv, and per-finding markdown, yet the gate still ends with No Strix vulnerability report artifact was produced; log-only severity markers are incomplete evidence and Unable to map Strix findings to changed files; failing closed for pull request. The successful fallback model completed finish_scan, wrote the final report, and logged Strix scan ... done; the wrapper still returned exit 2 after earlier NVIDIA NIM 429s / tool errors.

The artifact also demonstrates why recovery must validate report semantics rather than merely accepting the presence of a severity record: vuln-0001 is titled “No JWT Authentication Vulnerabilities Found”, says N/A - No vulnerabilities discovered and no immediate remediation is required, but is encoded as Severity: HIGH, CVSS 7.3. The final executive report simultaneously says no exploitable issues while the console summary says HIGH: 1. That contradictory record must not become a real source finding or merge-blocking vulnerability solely because a model emitted a severity field.

Please include this ScopeWeave exact-head canary in #952 acceptance: after the central fix, a completed durable report must be discovered from its authoritative output path, bound to the exact head/live-base scope, and semantically classified so a self-negating “no vulnerability found” record cannot be promoted to a HIGH finding. Provider/tool errors before a later successful complete scan remain diagnostic provenance, while unknown/incomplete evidence stays fail-closed. No ScopeWeave source change can causally repair this central scanner/runtime boundary, so I am not churning the clean contributor head with another expensive retry before the owner repair changes the failure condition.