fix(logging): keep verbose openai.agents DEBUG off sandbox stdout

[Zizouk22]

What

Keep the very verbose openai.agents SDK DEBUG output in the per-scan strix.log file only, and stop routing it to stdout.

Why

openai.agents is in _TRACKED_ROOTS and setup_scan_logging attaches both the file handler and the stdout stream handler to it at DEBUG. The SDK logs one DEBUG record per span / function-call / reasoning-item. The sandbox runs in Docker with the default json-file driver (no rotation), so stdout accumulates without bound — on a long run the container log grew to 80 GB+ and filled the host disk (details in #703).

Change

In setup_scan_logging, attach the stdout stream_handler to every tracked root except openai.agents. Its DEBUG stays in strix.log (bounded per-scan file); the strix logger keeps stdout. Minimal and behavior-preserving for Strix's own logs. Does not address the separate fd-leak (Errno 24) noted in the issue.

Fixes #703

[greptile-apps]

Greptile Summary

This PR stops the openai.agents SDK's verbose DEBUG output from reaching stdout (and therefore Docker's unbounded json-file log) by skipping the stream_handler attachment for that logger root while keeping the file_handler (bounded per-scan strix.log) intact.

• The core fix is correct and minimal: zip(_TRACKED_ROOTS, tracked_loggers) lets the loop key on the logger name, and the teardown function handles the asymmetric handler list without changes.
• The exclusion also removes WARNING/ERROR messages from openai.agents on stdout, not just DEBUG — operators or monitors that tail stdout for SDK errors will silently lose that signal.
• The magic string \"openai.agents\" is checked at the call site rather than co-located with _TRACKED_ROOTS, making the exclusion hard to discover when extending that tuple in the future.

Confidence Score: 4/5

Safe to merge for the intended goal; the one behavioural side-effect (WARNING/ERROR from openai.agents no longer appearing on stdout) is low-risk but worth a conscious decision before merging.

The change is narrow and the teardown logic handles the new asymmetric handler setup without modification. The only non-obvious consequence is that non-DEBUG messages from the openai.agents logger are also suppressed from stdout, which is a silent behaviour change from what the PR description describes.

strix/telemetry/logging.py — specifically the stream_handler exclusion at line 134 and the missing co-location of the exclusion constant with _TRACKED_ROOTS.

Important Files Changed

Filename	Overview
strix/telemetry/logging.py	Excludes openai.agents from the stdout stream_handler to prevent unbounded Docker log growth; file-only logging for that root is preserved. The exclusion also silently suppresses WARNING/ERROR-level output from openai.agents on stdout in addition to DEBUG.

Prompt To Fix All With AI

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

---

### Issue 1 of 2
strix/telemetry/logging.py:134-135
**ERROR/WARNING from `openai.agents` also silenced on stdout**

The guard `if name != "openai.agents"` removes the stream handler entirely, not just at DEBUG level. In production mode (`debug=False`) the stream handler runs at `ERROR`, meaning that before this change `openai.agents` ERROR records did reach stdout; after it they go only to `strix.log`. The PR description focuses on the DEBUG flood, but this is a silent secondary behaviour change. If operators or external monitors tail stdout for SDK errors (API failures, auth issues, etc.) they'll now miss them.

Consider attaching the stream_handler unconditionally and instead raising its floor for `openai.agents` to `WARNING` (or `ERROR`) to stop the DEBUG flood while keeping higher-severity signals visible on stdout.

### Issue 2 of 2
strix/telemetry/logging.py:134
**Exclusion list is not co-located with `_TRACKED_ROOTS`**

The string `"openai.agents"` appears only at the call site, disconnected from the `_TRACKED_ROOTS` definition at line 64. If a future contributor adds another chatty SDK to `_TRACKED_ROOTS`, there's no signal that this exclusion logic exists. A small named constant (e.g. `_STDOUT_EXCLUDED_ROOTS: frozenset[str] = frozenset({"openai.agents"})`) defined next to `_TRACKED_ROOTS` would keep the two declarations together and make the intent discoverable.

_{Reviews (1): Last reviewed commit: "fix(logging): keep verbose openai.agents..." | Re-trigger Greptile}

[greptile-apps]

ERROR/WARNING from openai.agents also silenced on stdout

The guard if name != "openai.agents" removes the stream handler entirely, not just at DEBUG level. In production mode (debug=False) the stream handler runs at ERROR, meaning that before this change openai.agents ERROR records did reach stdout; after it they go only to strix.log. The PR description focuses on the DEBUG flood, but this is a silent secondary behaviour change. If operators or external monitors tail stdout for SDK errors (API failures, auth issues, etc.) they'll now miss them.

Consider attaching the stream_handler unconditionally and instead raising its floor for openai.agents to WARNING (or ERROR) to stop the DEBUG flood while keeping higher-severity signals visible on stdout.

Prompt To Fix With AI

This is a comment left during a code review.
Path: strix/telemetry/logging.py
Line: 134-135

Comment:
**ERROR/WARNING from `openai.agents` also silenced on stdout**

The guard `if name != "openai.agents"` removes the stream handler entirely, not just at DEBUG level. In production mode (`debug=False`) the stream handler runs at `ERROR`, meaning that before this change `openai.agents` ERROR records did reach stdout; after it they go only to `strix.log`. The PR description focuses on the DEBUG flood, but this is a silent secondary behaviour change. If operators or external monitors tail stdout for SDK errors (API failures, auth issues, etc.) they'll now miss them.

Consider attaching the stream_handler unconditionally and instead raising its floor for `openai.agents` to `WARNING` (or `ERROR`) to stop the DEBUG flood while keeping higher-severity signals visible on stdout.

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

[greptile-apps]

Exclusion list is not co-located with _TRACKED_ROOTS

The string "openai.agents" appears only at the call site, disconnected from the _TRACKED_ROOTS definition at line 64. If a future contributor adds another chatty SDK to _TRACKED_ROOTS, there's no signal that this exclusion logic exists. A small named constant (e.g. _STDOUT_EXCLUDED_ROOTS: frozenset[str] = frozenset({"openai.agents"})) defined next to _TRACKED_ROOTS would keep the two declarations together and make the intent discoverable.

Prompt To Fix With AI

This is a comment left during a code review.
Path: strix/telemetry/logging.py
Line: 134

Comment:
**Exclusion list is not co-located with `_TRACKED_ROOTS`**

The string `"openai.agents"` appears only at the call site, disconnected from the `_TRACKED_ROOTS` definition at line 64. If a future contributor adds another chatty SDK to `_TRACKED_ROOTS`, there's no signal that this exclusion logic exists. A small named constant (e.g. `_STDOUT_EXCLUDED_ROOTS: frozenset[str] = frozenset({"openai.agents"})`) defined next to `_TRACKED_ROOTS` would keep the two declarations together and make the intent discoverable.

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

Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!

[Ruanyuxi1337]

LGTM! Verified that excluding 'openai.agents' from stream_handler correctly silences the verbose SDK debugging log flood from stdout (while preserving it in strix.log). All 86 tests passed successfully.