False-positive cyber_policy interrupts benign long-running local repository orchestration

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

• #36573
• #36569
• #37071

Powered by Codex Action

Additional reproduction: Codex Desktop + remote SSH task becomes terminal systemError

I encountered the same failure mode on 2026-08-10 during benign local-repository engineering.

Environment

• Originator: Codex Desktop
• Bundled/runtime CLI: codex-cli 0.146.0
• Model: gpt-5.6-sol, reasoning effort xhigh
• Execution host: Linux aarch64 in an OrbStack remote-SSH project
• Sandbox reported by the affected rollout: danger-full-access
• Approval policy: never
• Affected task/thread ID: 019fe41d-3c06-7951-b5df-055a8c6e246f

Benign workload

The task was implementing and independently reviewing a local multi-repository development-lifecycle/resource-cleanup component. It used project-local source edits, formal proofs, unit/conformance checks, Git state inspection, and read-only inventory/review agents.

It was not a cybersecurity task. There was no penetration testing, network scanning, credential retrieval, data exfiltration, third-party target, exploit development, or provider/resource effect. The code did include defensive local-filesystem safety checks (path containment, symlink/realpath handling, object identity, fail-closed deletion permits), which may be a classifier correlation but should not make the entire task unrecoverable.

Repeated failures

The task failed four times with the exact message:

This content was flagged for possible cybersecurity risk. If this seems wrong, try rephrasing your request. To get authorized for security work, join the Trusted Access for Cyber program: https://chatgpt.com/cyber

The user prompts that triggered the failed turns were only continuation requests:

| Turn ID | Prompt | Reported duration |
|---|---|---:|
| c1a23881-2f00-420f-862a-d1d1dda4d5c1 | 再開して (“resume”) | 3,551,159 ms |
| 019fe952-a0cf-7c11-8dad-6279fbb6f244 | 続けてください (“please continue”) | 3,213,654 ms |
| 019fe984-90aa-7d11-882c-2398dfd2ed20 | 続けて (“continue”) | 375,868 ms |
| 019fe98c-24f8-7ff3-be39-d3c759abd386 | 続けて (“continue”) | 22,517 ms |

The reported durations sum to about 1h59m23s. After the repetitions, the task itself was exposed by the app as status.type = systemError. Normal resume was not reliable; recovery required a fresh same-directory fork containing only completed history, followed by reconstruction of the unfinished active-turn state.

Expected behavior

• Benign repository engineering should not be classified as high-risk cyber activity.
• If a request-level safety check fires, it should be recoverable by rerouting or an actionable false-positive flow; it should not terminally poison the entire task.
• The app should preserve the unfinished task state, clearly identify whether the backend stopped, and provide a stable incident/feedback ID.
• Plain continuation prompts should not repeatedly re-trigger a terminal safety failure after substantial execution time.
• Resume/fork recovery should not require manually reconstructing the active turn and subagent/review state.

No raw transcript, source code, credentials, local paths, or provider data are attached publicly. A redacted event envelope can be provided privately if maintainers need it.

I encountered the same false-positive pattern in Codex Desktop while doing benign, authorized local C++ application-stability debugging.

Environment:

• Codex Windows App: 26.727.6591.0
• OS: Windows 10 / PowerShell 7
• Model: gpt-5.6-sol, ultra reasoning
• Thread: 019fef77-e078-7912-ae6e-f533bc5380b9
• Affected turn: 019fef9a-8deb-7a70-aa30-e8157a4c5111
• Failure time: 2026-08-11 07:34:18 UTC
• Error: codex_error_info: "cyber_policy"

The task was diagnosing a local spreadsheet application's UI hang using local crash logs, thread snapshots, Git history, and C++ source inspection. It did not request or perform security testing, scanning, exploitation, credential access, persistence, or access to any external target.

Measured details:

• The turn ran for about 39 minutes.
• 322 tool calls were made, all local/read-only source and log inspection such as rg, Get-Content, and git log/show.
• A scan of tool-call inputs found no curl, wget, ssh, scp, nmap, hdc, adb, URL, socket, payload, credential, token, or password command.
• The active compacted context reached approximately 198,947 tokens.
• The final successful action merely read lines 155-210 of a local C++ rendering source file. The next sampling request was rejected with cyber_policy, and no final answer was preserved.

This strongly suggests cumulative-context classification drift: dense kernel/thread logs, process identifiers, native stacks, memory-allocation failures, and low-level C++ rendering code appear to have made an ordinary debugging thread look security-related.

Impact:

• Roughly 39 minutes of analysis ended without a final response.
• The warning suggests Trusted Access even though the work was not cybersecurity work.
• The Desktop app provided no incident ID or one-click false-positive reporting path.

Requested improvements:

1. Classify long-running local crash/stability debugging by intent, not low-level vocabulary density.
2. Run safety review earlier, before a long turn consumes substantial time.
3. Preserve completed analysis or a recoverable draft when a later sampling request is blocked.
4. Show a stable incident/request ID and add a one-click “Report false positive” action.
5. Avoid directing non-security debugging users to Trusted Access.

No proprietary source, raw logs, credentials, or local paths are attached publicly. I can provide a narrowly redacted event envelope privately if maintainers need it.