[Codex App/macOS] Frequent cyber-safety false positives hide final responses during benign local audio-tool development

Open 💬 3 comments Opened Jul 23, 2026 by SolarMo-xs
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

Feedback ID

019f8e0e-ce23-7890-b2f1-344e8abb0409

The in-app feedback, including a screenshot of the blocked response, has already been uploaded under this ID.

Environment

  • Codex App on macOS
  • macOS 12.5 (21G72), Intel x86_64
  • Model shown in the affected task: GPT-5.6 Sol, high reasoning
  • Codex App version was not visible in the captured UI; please correlate it through the Feedback ID

Summary

Over the last several days, Codex App has repeatedly classified ordinary local software-development work as a cybersecurity request. In the latest event, the assistant spent about 39 minutes preparing a local Pro Tools WAV-export test package, successfully made extensive filesystem edits, and ran offline tests. When it attempted to provide the final progress/review message, the App replaced the response with:

This content can’t be shown. We take extra caution with cybersecurity requests. If you’re a security professional, you may be able to apply for Trusted Access.

This was not cybersecurity work. It was a local audio-workflow development task.

Benign scope of the affected task

The task was preparing an offline test package for a Pro Tools batch WAV-export utility. It involved:

  • local Python code and Markdown documentation;
  • deterministic synthetic WAV/RIFF fixture generation and inspection;
  • local output-path collision checks;
  • a small state machine limiting an eventual audio test to two WAV bounces;
  • fake/mock client boundaries and offline unit tests;
  • package manifests and checksums.

The task instructions explicitly prohibited:

  • network access or remote targets;
  • running Pro Tools, PTSL, or the local ptslcmd client;
  • executing any WAV bounce;
  • accessing credentials or user audio;
  • transferring the package;
  • penetration testing, scanning, exploitation, persistence, or third-party access.

The UI showed that substantial benign work had already completed (33 edited files, approximately +4,544/-15 lines, and 72 offline PoC tests) before the final response was hidden.

Steps that led to the issue

  1. Open a local Codex App task for a Pro Tools audio-tool repository.
  2. Ask Codex to prepare, but not run, a local test package for two future WAV-export cases.
  3. Explicitly prohibit networking, remote access, live Pro Tools/PTSL calls, package transfer, and user-audio access.
  4. Let Codex implement local Python modules, synthetic audio fixtures, documentation, and offline tests.
  5. After the local edits and tests complete, Codex attempts to summarize its work.
  6. The final response is hidden by the cybersecurity classifier and the task cannot provide its completion report.

The exact trigger is unknown. Benign engineering terms such as client, streaming response, target package, state machine, fail-closed, and concurrent run protection may have been interpreted without the surrounding Pro Tools audio context.

Expected behavior

  • Local audio-tool development should complete normally.
  • Benign uses of generic engineering terminology should be interpreted in the surrounding domain context.
  • If an additional policy check is triggered, it should not discard the final response after successful file edits and tests.
  • The App should provide a stable continuation/recovery path and preserve a visible trace/correlation ID.
  • A false positive should not imply that Trusted Access for Cyber is required for ordinary local audio software work.

Actual behavior and impact

  • The final assistant response was lost after approximately 39 minutes of successful work.
  • The working tree remained dirty and partially completed, forcing a separate recovery session.
  • The user had to inspect the repository manually to determine whether work was preserved.
  • Repeated false positives over several days have interrupted normal development and made long-running Codex tasks unreliable.
  • Re-running from scratch could duplicate writes or discard valid local work, so recovery requires extra supervision.

Why this appears to be a false positive

There was no network target, security assessment, exploit, credential access, malware behavior, or unauthorized action. The terms that may resemble security language were used only for safe local file handling, deterministic audio-test orchestration, and preventing duplicate WAV export operations.

Related reports

  • #34228 — a benign local engineering task loses its final response to cyber_policy
  • #33836 — repeated cyber warnings for non-cyber work

This macOS audio-development case provides a separate Feedback ID and a different benign domain for classifier review.

Requested action

  1. Review Feedback ID 019f8e0e-ce23-7890-b2f1-344e8abb0409 as a likely false positive.
  2. Tune classification to preserve the surrounding local audio-development context.
  3. Avoid discarding final responses after successful tool work.
  4. Provide an explicit, recoverable task state and a stable trace ID when a response is blocked.
  5. Clarify that ordinary local software engineering does not require Trusted Access merely because generic terms such as client, state machine, or fail-closed appear.

No source code, SDK files, credentials, user audio, private logs, or absolute local paths are included in this public report.

View original on GitHub ↗

3 Comments

github-actions[bot] contributor · 1 month ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

  • #34791
  • #34228
  • #34257
  • #34725

Powered by Codex Action

SolarMo-xs · 1 month ago

Additional screenshot evidence

Two additional screenshots from the same affected task further narrow the false positive:

  1. Long-running completion screen: the task had processed for 39m 39s, completed the first round of 72 PoC-07 offline tests, and explicitly stated that it had not started or called Pro Tools, PTSL, or ptslcmd, and had not transferred the target package. Immediately below that benign progress, the App displayed the cybersecurity-content block instead of the final response.
  2. Beginning of the same task: before implementation, Codex repeatedly stated that the work was limited to local repository files, reviewed documentation, a read-only proto, fake tests, and offline packaging. It explicitly said it would not perform network searches, would not start or probe ptslcmd, would not connect to Pro Tools/PTSL, and would not trigger a live client. The cybersecurity-content block still appeared later in the same local audio-development task.

Together, these screenshots show that the false positive was not caused by an ambiguous user request: both the user instructions and the assistant’s own plan repeatedly established a non-networked, non-live, local Pro Tools audio-tool scope.

SolarMo-xs · 1 month ago

Original screenshots for the additional evidence described above:
<img width="885" height="618" alt="Image" src="https://github.com/user-attachments/assets/caa2c235-b7e4-45f4-8bcc-e996bb16bf76" />
<img width="953" height="731" alt="Image" src="https://github.com/user-attachments/assets/3c6c5d5d-6a4a-4fdc-a65b-d3baf00a8c18" />
<img width="847" height="696" alt="Image" src="https://github.com/user-attachments/assets/a7439ff0-cd9a-4611-8c36-7fe3dc55ac7c" />