[CLI] Sticky cyber-safety false positive during benign media-player development on owned LG TV

What version of Codex CLI is running?

0.147.0

What subscription do you have?

Plus

Which model were you using?

gpt-5.6-sol, high reasoning

What platform is your computer?

NixOS Linux x86_64

What terminal emulator and version are you using (if applicable)?

kitty

Codex doctor report

not run / not captured before the false-positive interruption

What issue are you seeing?

Codex CLI repeatedly replaced otherwise normal development output 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 occurred during benign media-player / hardware-integration development on a television that I personally own, on my private LAN, with the TV intentionally in LG Developer Mode.

The work was to implement and debug Moonfin Broker, a native media playback engine. The immediate task was an isolated one-access-unit H.264 decoder probe after an earlier decoder-integration bug caused the owned TV to reboot. The probe intentionally reduced risk by feeding exactly one known IDR access unit, capturing evidence off-device, and stopping deterministically.

The affected work included ordinary development operations such as:

• compiling a native C probe;
• packaging it as an LG Developer Mode IPK;
• launching that package on the owned TV;
• SSH diagnostics to the owned TV;
• reachability monitoring so a reboot would not erase the failure boundary;
• reading /proc/rtkvdec diagnostics exposed by the development environment;
• validating callback, buffer-ID, timestamp, and decoder-feed semantics.

There was no third-party target, credential access, authentication bypass, persistence/evasion, data exfiltration, malware development, or network intrusion.

The false positive also appears sticky at the session level rather than tied cleanly to a particular unsafe action:

1. The warning first appeared while Codex was creating the bounded probe/build/package/run harness.
2. Even a subsequent trivial user message (bruh hello?) received the same block.
3. Supplying an explicit task-classification message stating that the TV was personally owned and the work was authorized local application development temporarily allowed the session to continue.
4. The warning then returned after Codex made only a host-side C portability fix: defining _POSIX_C_SOURCE 200809L and replacing usleep() with a small nanosleep() helper because strict C11 hid the declarations.
5. Codex explicitly stated that nothing from that revised probe had reached the TV before the classifier blocked the response again.

That last trigger is especially useful: the visible edit itself was ordinary POSIX portability code, suggesting the accumulated session context or classifier state was driving the block rather than the immediate requested operation.

What steps can reproduce the bug?

Uploaded thread: 019ffddb-993f-7361-ad6f-9b69db66cb33

Representative workflow:

1. Open Codex CLI in a local media-player repository.
2. Work on native decoder integration for a personally owned LG TV in Developer Mode on a private LAN.
3. Create a narrowly bounded one-AU H.264 test probe and supporting build/package scripts.
4. Include normal device-development diagnostics such as SSH to the owned TV, IPK installation/launch, reachability monitoring, and reading exposed decoder status from /proc.
5. Observe the cybersecurity block despite the benign/authorized context.
6. Clarify explicitly that the hardware is personally owned and that the task is application/media-player development; observe that the session can resume.
7. Continue with a mundane C portability edit (_POSIX_C_SOURCE, nanosleep) before any deployment; observe the cybersecurity block recur.

What is the expected behavior?

Authorized local device/application development on personally owned hardware should not be classified as a harmful cybersecurity request merely because the workflow contains SSH, remote package launch, /proc diagnostics, hardware-decoder debugging, or crash/reboot monitoring.

If an individual operation genuinely requires additional caution, Codex should scope the restriction to that operation or ask for clarification rather than hiding all subsequent responses and effectively poisoning the session.

Once the task context clearly establishes owned hardware, private-LAN development, and no unauthorized target, ordinary C/build/debug work should proceed normally.

Additional information

The CLI itself generated a /feedback report and instructed the user to open an issue or mention thread ID 019ffddb-993f-7361-ad6f-9b69db66cb33.

Related reports include #34306, #34791, and #34913. This report adds a distinct signal: the block temporarily cleared after explicit benign task classification, then recurred on a mundane host-side POSIX portability edit before any device execution, suggesting a sticky/context-level false-positive state.

Authorship note: Drafted by ChatGPT (GPT-5.6 Sol) from the user-provided Codex transcript/logs and submitted at the user's explicit request. The factual development context and observations above come from that transcript.