codex - 💡(How to fix) Fix Codex App: false-positive safety-risk stops interrupt benign browser QA and benchmark sessions

What version of the Codex App are you using (From “About Codex” dialog)?

Observed in Codex Desktop session logs across:

• 0.118.0-alpha.2
• 0.130.0-alpha.5

Current session log reports 0.130.0-alpha.5.

What subscription do you have?

Not available from local session logs.

What platform is your computer?

Darwin 25.4.0 arm64 arm

What issue are you seeing?

Codex App conversations are being stopped by a safety-risk gate during benign, user-authorized software engineering work. The local JSONL session logs do not expose the internal classifier verdict, so the evidence below is based on the user-visible symptom pattern:

• an in-progress turn ends with task_complete but an empty last_agent_message;
• the user immediately reports that the thread was stopped or flagged;
• the surrounding task is ordinary repo-local QA, benchmark, browser-proof, model-provider telemetry, or dashboard work;
• no credentials are printed, no auth bypass is requested, no payment/action is completed, and the workflows include explicit stop boundaries.

Uploaded thread reference from the issue URL:

Uploaded thread: 0ce8e98a-7678-47c4-997b-ef2a9209d861

What steps can reproduce the bug?

I found the following instances in local Codex session logs. Session IDs are included so the uploaded thread/log bundle can be correlated server-side.

Concrete reproduction shape:

1. In Codex App, work in an owned repo that performs browser QA/acceptance testing.
2. Ask Codex to run user-authorized browser proof against public product pages with guardrails: dummy data only, no login, no account creation, no payment, no irreversible submit.
3. Ask Codex to classify failures such as 403/site-protection pages separately from selector bugs and surface the stats in a dashboard.
4. The session may terminate mid-turn with an empty completion event instead of allowing Codex to continue or ask for clarification.

What is the expected behavior?

Codex should not stop benign software-engineering sessions just because the repo uses browser automation, acceptance proof, model-role benchmarking, or failure classification language.

Expected handling:

• Use repo and conversation context, including explicit user authorization and hard stop boundaries.
• Treat guardrails such as “no login”, “no accounts”, “no payment”, and “dummy data only” as risk-reducing signals, not risk-increasing signals.
• Allow defensive QA labels for site-protection or rate-limit failures in benchmark dashboards.
• If the classifier is uncertain, ask a targeted clarification or downgrade capabilities for that turn rather than killing the session.
• Preserve a user-visible error reason in the JSONL/logs instead of only an empty task_complete marker.

Additional information

The repeated false positives caused large amounts of duplicate work because the user had to start new threads and re-prompt with less precise language. The worst case is that safer guardrail language appears to increase false positives, which encourages users to provide less safety context.

No secrets were included in this issue. Local dotenv discovery in the affected sessions reported only paths/source availability and did not print key values.