[BUG] openai.agents DEBUG floods sandbox stdout -> fills host disk (80GB+); + Too many open files (Errno 24) on long runs

[Zizouk22]

Summary

On a long-running scan, the strix-sandbox container's stdout (captured by Docker's json-file driver, no rotation) grew to 80+ GB and filled the host disk. Two related problems:

1. Verbose openai.agents DEBUG is routed to stdout (unbounded)

strix/telemetry/logging.py lists openai.agents in _TRACKED_ROOTS and, in setup_scan_logging, sets it to logging.DEBUG and attaches both the file handler and the stdout stream handler. The openai-agents SDK emits one DEBUG record per span / function-call / reasoning-item:

DEBUG  openai.agents: Tracing is disabled. Not creating span <...FunctionSpanData...>
DEBUG  openai.agents: Processing output item type=function_call class=ResponseFunctionToolCall
DEBUG  openai.agents: Processing output item type=reasoning class=ResponseReasoningItem

These dominate the output (hundreds of near-identical lines per scan-second). Because the sandbox runs in Docker with the default json-file driver (no rotation), stdout accumulates without bound — the container json log reached ~80 GB and filled /. The container also keeps running and logging after the run prints Strix scan <id> done, compounding the growth.

2. File-descriptor leak -> OSError: [Errno 24] Too many open files

File "strix/core/agents.py", line 306, in _maybe_snapshot
    with tempfile.NamedTemporaryFile(...) as tmp:
OSError: [Errno 24] Too many open files: '.../.state/.agents.json._....tmp'

_maybe_snapshot uses a context manager (closes correctly), so the fds are exhausted elsewhere (long-lived HTTP/browser resources over the run); the tempfile is just the first op to hit the limit.

Impact

A single long scan can fill the host disk (observed 80 GB) and pause/crash the sandbox.

Environment

• Image ghcr.io/usestrix/strix-sandbox:1.0.0
• Docker default json-file log driver (no rotation)

Suggested fixes

1. Don't route the ultra-verbose openai.agents DEBUG to stdout — keep it in the per-scan strix.log file only. (PR opened.)
2. Consider a RotatingFileHandler for strix.log, and/or document a recommended --log-opt max-size.
3. Investigate the fd leak surfacing at _maybe_snapshot (Errno 24).