2874abbfec
Round 6 reviewer noted that the warn-and-proceed path in `_start_thread_with_system` is "failing open" on a server-side chat surface: an SDK rev that does not expose ApprovalMode or SandboxMode would log a warning then call `thread_start(model=...)` with NO safety kwargs, letting the model run under the SDK's `auto_review` default. For a route that takes a user-controlled prompt and can spawn shell commands or file writes, that is the wrong tradeoff. Now fails closed: when `_safe_thread_safety_kwargs()` returns the empty dict the helper raises `CodexUnavailableError`, which the route layer translates to a 503 with a clear error message telling the operator to upgrade `openai_codex` (or set the explicit override env var). The error message names the override so users who hit this on a pre-release alpha can opt in with eyes open rather than discovering the unsafe default after the fact. `UNSLOTH_CODEX_ALLOW_UNSAFE_DEFAULTS=1` is the deliberately-verbose escape hatch. Variable name long and explicit so it does not creep into production environments by accident, kept on the codex subprocess safe-list so the round 6 SDK env-scrub wrapper does not delete it before the gate sees it. Tests: 50 cases total (was 49). The previous old-SDK test was renamed and replaced by two new ones: - `test_thread_start_fails_closed_when_safety_unavailable` asserts the raise fires and `thread_start` is never called. - `test_thread_start_allows_unsafe_defaults_with_explicit_opt_in` asserts the override env var lets the request through and `thread_start` runs without the safety kwargs (with a logged warning). The `_install_fake_codex_sdk` helper now injects fake ApprovalMode and SandboxMode by default so the general translation tests do not need to opt into the override; the two round-6b tests above pass `with_safety_enums=False` to exercise the fail-closed branch. |
||
|---|---|---|
| .. | ||
| data_recipe | ||
| export | ||
| inference | ||
| training | ||
| __init__.py | ||
| tool_healing.py | ||