[Windows App 26.715.4045.0] Benign process-lifecycle design review ends in cyber_policy and "Task encountered a system error" #34228

Codex version

• Codex Windows App: 26.715.4045.0
• Bundled runner: 0.145.0-alpha.18
• Platform: Microsoft Windows NT 10.0.26200.0 x64

Summary

A benign, defensive, local-only architecture review was blocked at final-response generation with cyber_policy, and Codex Desktop surfaced the result as Task encountered a system error.

The task was designing a source-only Windows process-lifecycle POC for cleaning up Codex-owned orphaned MCP subprocess trees after an explicit task/subagent shutdown. The underlying lifecycle defect is already reported in #33531. This task did not perform penetration testing, exploitation, scanning, persistence, credential access, or operations against a third party.

During the affected turn, Codex only read official openai/codex source, reviewed Microsoft Job Object semantics, and edited two local Markdown design documents. It did not terminate any process, run the proposed POC, modify the installed Codex app, or change Codex configuration/state.

Exact failure

At 2026-07-19 23:50:00.373 MSK (UTC+3), the turn ended with:

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 recorded error class was:

codex_error_info = cyber_policy

The Desktop UI also showed:

Task encountered a system error

Turn ID for internal correlation:

019f7c15-f7e0-7a71-9154-295b1ae6d0e5

No request/correlation ID was present in accessible local telemetry.

Timeline

Windows Application/AppModel logs showed no synchronous crash or app termination, and Codex remained running. This was a policy-classifier rejection, not a Windows crash.

A later native thread readback reported the affected turn as status=completed and error=null, which conflicts with the canonical rollout's cyber_policy terminal event.

Defensive scope of the task

The design itself required:

• only isolated source builds and subprocesses created by the test;
• exact process handles and creation-time verification;
• no PID/name-based process cleanup;
• fail-closed Windows Job Object containment;
• no unmanaged fallback;
• no installed-package probe;
• no Desktop/global integration without separate approval;
• no credentials, remote target, exploit, malware, or third-party access.

The document used terms such as TerminateProcess, Job Objects, KILL_ON_JOB_CLOSE, crash, process handle, and taskkill solely to design safe ownership, cleanup, negative tests, and rollback. These terms may have contributed to the classifier result, but the exact trigger is not available in local telemetry.

Steps that led to the issue

1. Open a Codex Desktop task on Windows.
2. Review a defensive design for owner-scoped cleanup of orphaned local MCP process trees.
3. Compare the design with pinned official Codex source and Microsoft Job Object documentation.
4. Apply Markdown-only corrections covering shutdown state, process ownership, test cleanup, and race handling.
5. Attempt to produce the final review summary.
6. Observe the Trusted Access/cyber-risk message followed by Task encountered a system error.

This is an evidence report, not a claim that every repetition will trigger the classifier; the exact classifier feature/phrase is not exposed.

Expected behavior

• Benign local resource-lifecycle engineering should complete normally.
• An additional safety check should not be presented as evidence that the user violated policy.
• If output is blocked, Desktop should show the exact policy reason rather than a generic system-error message.
• Rollout, native thread status, and UI state should agree.
• A request/correlation ID should be available for support and classifier tuning.
• Successful local tool work should remain recoverable and the task should be safely continuable.

Actual impact

• The final answer was lost after successful edits.
• The UI made a policy rejection look like an app/system failure.
• The Trusted Access wording made a benign user believe they were being accused of unauthorized activity.
• The task required a recovery turn and was left partially completed until then.

Related issues

• False positive on cybersecurity requests #33810 — related Trusted Access / content-blocking report
• False-positive cybersecurity block for local MySQL MTR regression testing #33302 — related authorized isolated local regression work blocked as cyber
• False positive cyber-safety flag on benign software engineering work #19533 — earlier benign software-engineering false positive; closed after acknowledgement
• [Windows App 26.707.9981.0] MCP suites persist after subagents complete, reaching 10.9 GB private memory #33531 — underlying Windows MCP lifecycle/process-retention problem; this issue does not duplicate it

Suggested product fixes

1. Include owner-scoped local process-lifecycle and documentation-only context in classifier tuning.
2. Do not map cyber_policy to a generic Task encountered a system error banner.
3. Preserve the terminal error consistently across rollout, native thread readback, and UI.
4. Surface a request/correlation ID and an in-product feedback path.
5. Allow a safe continuation/retry after tool work has already completed.

No usernames, absolute paths, PID values, raw command lines, credentials, document contents, or private logs are included.

Why this defensive work was necessary

This was not a hypothetical process-control exercise. It was a response to repeated, measurable resource retention by Codex Desktop itself on the user's own Windows machine. The user first asked Codex to explain why Codex was consuming enough CPU and memory to make other work difficult, then asked for a narrowly scoped design for deterministic cleanup of Codex-owned child processes.

Sanitized point-in-time evidence collected before the blocked turn includes:

• up to 552 app-server descendants;
• a clean Codex-tree checkpoint with 354 processes, 17.88 GB private memory, and 24.9% CPU;
• 11 complete, structurally identical 13-process MCP suites alive concurrently: 143 MCP processes using 9,575.5 MB private memory;
• five code-mode kernels that remained alive for more than eight hours, using 32.617% of total-machine CPU and 7,550 MB private memory, while the app-server used another 8.125%;
• a simultaneous native task-status checkpoint of only 2 active, 5 idle, and 27 notLoaded tasks.

The measurements do not prove exact per-task ownership for every MCP suite, and they do not prove that every retained suite is a permanent orphan. Natural cleanup was partial rather than absent: over one ten-minute idle checkpoint, 11 suites became 9, descendants fell from 312 to 251, and private memory fell from 11,659.7 MB to 9,528.9 MB. The remaining footprint was still large enough to justify product-level lifecycle investigation.

One separately authorized selective cleanup removed only three processes already proven to belong to an idle task. Their runners exited naturally, protected active-task processes remained untouched, and measured total CPU fell from 45.02% to 21.39%. This historical diagnostic action is context only; no process was terminated in the turn that received cyber_policy.

User time, context, and reliability impact

The lifecycle diagnosis, defensive design, and recovery span 29 completed relevant root turns with a non-overlapping recorded duration of 34,244,650 ms (09:30:44.650). Parallel subagent turns were excluded to avoid double-counting. The exact scoped token count is unavailable, so this report does not estimate it.

All selected relevant turns were recorded with gpt-5.6-sol at ultra reasoning effort. The user spent substantial time supervising evidence collection because the product did not expose reliable process ownership, reuse, cleanup-completion telemetry, or a supported owner-scoped cleanup control. The retained processes caused real UI/mouse lag and repeatedly consumed multi-gigabyte memory. After that investment, the final answer of the defensive design review was lost to a safety classification even though the Markdown edits had already succeeded.

Why this appears to be a false positive

The affected turn was restricted to official source inspection, documentation review, and local Markdown edits. It did not:

• build or run a process-lifecycle POC;
• terminate any process;
• modify installed Codex, WindowsApps, persistent Codex configuration/state, Windows settings, services, or security controls;
• scan a network or target a third party;
• access credentials;
• perform exploitation, persistence, evasion, malware activity, or unauthorized access.

The proposed POC was deliberately narrower than ordinary process-management code: isolated source build, synthetic test-created processes only, exact handle ownership, fail-closed Job Object containment, no PID/name-based cleanup, no unmanaged fallback, and no Desktop integration without separate approval.

OpenAI's official Cyber Safety guidance acknowledges that legitimate or non-cybersecurity activity can be classified incorrectly and directs users to report such cases through /feedback. A Feedback ID is not yet available: this automation runtime exposes no native feedback submission method, and its Windows-automation safety rules prohibit controlling the Codex Desktop UI. The affected turn ID and exact terminal event are preserved above.

Request for human review and actionable guidance

We are not asking OpenAI to bypass safeguards or authorize arbitrary process termination. We are asking for a human determination and a supported path for fixing a Codex resource-lifecycle problem on the owner's own machine.

Please:

1. Review this event as a likely false positive and use the preserved turn ID for classifier tuning.
2. Confirm whether narrowly scoped, owner-authorized local process-lifecycle engineering for Codex-created synthetic child processes is permitted.
3. If any part is not permitted, identify the exact prohibited operation and the supported safe alternative; a generic Trusted Access invitation does not answer that engineering question.
4. Confirm whether this one additional-check event, by itself, represents an established Usage Policy violation or any negative account/access status.
5. Fix the UI/status mismatch so cyber_policy is not presented as a generic system error and later read back as completed / error=null.
6. Provide a request/correlation identifier and an in-product false-positive path that remains usable after the original turn has been blocked.
7. Clarify whether Trusted Access is actually required for this strictly local defensive systems-engineering work, or whether ordinary false-positive review is the intended route.

The desired outcome is straightforward: either allow this legitimate local reliability work to continue under clear guardrails, or state precisely what must stop and what supported alternative should be used.