GPT-5.6 classifiers interrupt legitimate blue-team work and Codex App becomes operationally unusable

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

26.707.31428

What subscription do you have?

ChatGPT Pro 20x

What platform is your computer?

Windows 11 Pro + WSL2

What issue are you seeing?

Codex Desktop + GPT-5.6 Operational Usability Incident Report

Report date: 2026-07-10
Reporter timezone: Europe/Madrid
Product surface: Codex Desktop on Windows with execution inside WSL2
Application branding: Powered by Codex & OWL
Application version: 26.707.31428
Application release date: 2026-07-10
Model observed: GPT-5.6 Sol, Light reasoning
Impact severity: High for legitimate security-engineering workflows
Status: Unresolved; reporter discontinued use of Codex Desktop

Executive Summary

Codex Desktop introduced enough execution overhead and safety-interruption friction to make a legitimate security-engineering task operationally unusable.

Three related failures were observed:

1. Legitimate blue-team and control-plane-adjacent work triggered security classifiers across both Codex Desktop and CLI workflows, interrupting otherwise authorized defensive engineering.
2. In Codex Desktop, one security-interruption modal became effectively non-actionable. It offered only Learn more or retry with a slower model, with no clear acknowledgement or continuation control. Closing the modal and manually entering continue allowed the underlying task to resume.
3. A bounded implementation task then spent 1 hour, 55 minutes, and 47 seconds in active execution without completing. The workflow became trapped in repeated serialized implementation and review cycles, with limited visibility into whether time was being spent on model reasoning, safety review, subagent execution, retries, or application orchestration.

The task was stopped manually. The reporter will not intentionally reproduce the modal because the incident was costly and disruptive.

User Impact

• Nearly two hours of active execution were consumed without task completion.
• The task remained unfinished at the installer/rollback stage.
• The desktop interface provided poor progress visibility during long-running work.
• A security prompt interrupted a legitimate defensive workflow and did not provide a usable acknowledgement path.
• Related classifier interruptions have also occurred during legitimate CLI-based blue-team and control-plane-adjacent work.
• The reporter abandoned Codex Desktop and returned to a terminal-based workflow.
• The reporter is considering GPT-5.5 High as the daily execution model and GPT-5.6 only as a bounded review model.

For this workflow, Codex Desktop was materially slower and less controllable than running Codex from a terminal inside the same Linux environment. However, the classifier problem is not limited to the Desktop application: the Desktop surface adds UI and orchestration failures, while the broader safety-interruption behavior also affects CLI execution.

Environment

• Windows desktop application
• WSL2 Linux execution environment
• Repository-based software-engineering task
• Git worktree isolation
• Subagent-driven implementation with independent review gates
• MCP tooling involved
• Short-lived credentials fetched at runtime
• No credential was intended to be persisted in configuration, files, logs, command-line arguments, or inherited environment

The affected Codex Desktop build was 26.707.31428, branded Powered by Codex & OWL, released 2026-07-10.

Broader Classifier Scope

The reported issue is broader than one Desktop modal or one repository task.

The reporter has observed security classifiers interrupting other legitimate work in two recurring categories:

• Blue-team engineering: defensive review, hardening, authentication, credential handling, audit, remediation, and security validation.
• Control-plane-adjacent engineering: orchestration, policy enforcement, tool routing, MCP integration, evidence handling, execution gates, session recovery, and infrastructure that can resemble security-sensitive control logic despite being defensive and internally authorized.

These interruptions have occurred in CLI workflows as well as in Codex Desktop.

The distinction is important:

• Model/classifier issue: benign defensive or infrastructure work is being classified in a way that interrupts execution.
• Desktop product issue: Codex Desktop handles those interruptions poorly, adds opaque latency, and can leave the user without a clear acknowledgement or continuation path.
• Combined effect: workflows that already encounter classifier friction become substantially less usable in the Desktop client.

This report does not claim that every interruption is a false positive. It claims that the current behavior is overbroad enough to materially disrupt recurring legitimate engineering work and lacks an effective mechanism for acknowledgement, correction, or durable user feedback.

Legitimate Task Context

The task was to implement a secure local bridge between Codex and an existing MCP service.

The bridge design required:

• runtime retrieval of a short-lived credential;
• no secret persistence to disk;
• STDIO-facing MCP integration;
• upstream Streamable HTTP session handling;
• bounded credential refresh;
• no replay of ambiguously completed writes;
• sanitized diagnostics;
• safe global configuration updates;
• transactional install and rollback behavior.

This was a defensive infrastructure task intended to improve secret handling and remove reliance on inherited interactive-shell state.

Incident A: Non-Actionable Security Modal

Observed behavior

During legitimate security-related work, Codex Desktop displayed a security-interruption modal with only these apparent options:

• Learn more
• Retry with a slower model

There was no clear acknowledgement, dismissal-and-continue, or “I understand” action.

The reporter closed the modal and typed continue into the task. Execution resumed.

Expected behavior

A safety interruption should:

• explain what category triggered the interruption;
• provide a usable acknowledgement or appeal path for legitimate defensive work;
• clearly state whether the current turn was cancelled, paused, or still running;
• allow the user to continue safely without guessing at hidden application state;
• preserve a reportable incident identifier.

Actual behavior

The interface left the user uncertain whether:

• the model turn had stopped;
• the backend was still active;
• the task was awaiting acknowledgement;
• retrying would duplicate work;
• closing the modal would discard state.

Because manual dismissal followed by continue resumed execution, the observed behavior is consistent with possible UI/backend state desynchronization. This is a hypothesis, not a confirmed root cause.

Reproduction status

The reporter will not intentionally reproduce this issue. The original event was disruptive and the modal was not captured before it cleared.

Incident B: Excessive Execution Overhead

Measured duration

The task log recorded:

• Active execution: 1:55:47
• Final state: incomplete
• Stop reason: reporter manually terminated the run because the execution time was excessive

Work completed

The session completed and reviewed:

1. dependency/runtime lock;
2. credential boundary;
3. replay policy;
4. relay/transport layer;
5. configuration editing.

The session did not complete:

1. installer and rollback layer.

Review-loop behavior

The workflow repeatedly serialized implementation and review:

• The relay task required five review-driven hardening passes.
• The installer task underwent multiple architectural corrections.
• Each new edge case became blocking.
• The final unresolved defect concerned cross-version rollback metadata binding.
• The task had not converged when the reporter stopped it.

Examples of issues discovered during the run included:

• secret material temporarily written to disk;
• pathname validation separated from execution;
• response misassociation risk;
• diagnostic payload leakage;
• concurrent logging sanitization leakage;
• sleeping timeout-task leakage;
• pending callers stranded after terminal session failure;
• unsafe TOML boundary handling;
• installer trust-root defects;
• idempotence regressions;
• incorrect rollback digest binding across versions.

The review quality was often useful. The operational problem was that the application provided no effective budget, convergence boundary, or transparent explanation for why the run continued for nearly two hours.

Timeline Summary

Times are local to Europe/Madrid.

| Approximate time | Event |
|---|---|
| 14:49 | Reporter authorized proceeding |
| 14:50–16:43 | Architecture, design, dependency, and execution-plan work |
| 16:48 | Reporter selected subagent-driven execution |
| 17:06 | Long-running implementation phase began |
| 18:54 | Task still running; installer review remained unresolved |
| 19:02 | Reporter requested checkpoint and handoff because execution was unacceptably slow |
| After 19:02 | Active implementation was interrupted and checkpoint/handoff attempted |

The log separately displayed an active-work duration of 1:55:47.

Expected Product Behavior

For a first-class desktop engineering client, the expected behavior is:

• execution speed reasonably comparable to the terminal client;
• clear distinction between model reasoning, tool execution, safety review, retries, and queued subagents;
• interruptible and resumable tasks;
• bounded review loops;
• actionable safety prompts;
• reliable checkpoint and handoff;
• no opaque multi-hour “working” state.

Actual Product Behavior

• Execution was substantially slower than the reporter’s terminal workflow.
• Long-running work was opaque.
• The safety prompt had no usable acknowledgement path.
• Repeated review cycles continued without an effective convergence budget.
• The task remained incomplete after nearly two hours of active execution.
• The reporter had to terminate the session manually.
• Checkpointing was complicated by the same missing MCP integration the task was intended to repair.

Feedback Intake Failure

The reporting process exposed an additional product problem: there is no obvious, documented private engineering-feedback channel suitable for rich Codex incident data.

The available paths create an unfavorable choice:

• post a redacted report publicly in the Codex issue tracker;
• submit in-product feedback that may include logs or conversation content beyond the narrowly intended evidence;
• use general support without a clear guarantee that the report will reach the relevant Codex, safety, or classifier engineering teams.

For security-sensitive and proprietary development workflows, the underlying evidence can contain:

• private source code;
• repository structure;
• internal host and service names;
• authentication and credential-handling details;
• control-plane architecture;
• security findings;
• customer or organizational context;
• prompts and agent traces that reveal non-public operating procedures.

The reporter should not have to choose between withholding useful evidence and disclosing excessive raw data.

This creates a direct irony: the product requests user feedback to improve safety, classifiers, and developer experience, but the feedback mechanism does not provide an easy way to improve those mechanisms without risking disclosure of the very data that makes the report valuable.

Requested feedback-channel improvements

• Provide a documented private intake route for Codex and safety-classifier incidents.
• Allow submission of a redacted report before any diagnostic bundle is attached.
• Let the reporter explicitly select which logs, prompts, files, and metadata are included.
• Show a complete preview of the data package before submission.
• Document retention, access scope, training use, and deletion behavior for submitted evidence.
• Support scoped follow-up uploads requested by an identified engineering or safety team.
• Provide a stable case identifier and confirmation that the report reached the appropriate product team.
• Permit high-level classifier feedback without requiring reproduction or wholesale session disclosure.

Requested Investigation

Please investigate:

1. Whether GPT-5.6 security review is repeatedly reclassifying or re-evaluating benign defensive tasks.
2. Whether the classifiers are over-triggering on blue-team and control-plane-adjacent terminology, code, or tool use.
3. Whether the same interruption events are handled consistently across CLI and Desktop surfaces.
4. Whether Codex Desktop adds orchestration or IPC latency not present in terminal-based Codex execution.
5. Whether safety modals can become detached from the actual backend task state.
6. Why the modal lacked an acknowledgement or explicit continuation control.
7. Whether subagent review loops have a configurable time, iteration, or token budget.
8. Whether the UI can expose:

• current active agent;
• current stage;
• safety-review state;
• queued work;
• elapsed model time;
• elapsed tool time;
• retry count;
• review-cycle count.

1. Whether a session-level diagnostic bundle can be exported after the modal has cleared.
2. Whether legitimate security-engineering users can submit a false-positive classification without reproducing the incident.
3. Whether trusted defensive-work context can be carried across a session so the same authorized workflow is not repeatedly reclassified.
4. Whether classifier events can expose a category, confidence, and stable incident identifier without revealing sensitive internal policy details.
5. Why there is no clear private engineering-feedback intake for Codex incidents involving proprietary or security-sensitive evidence.
6. Whether in-product feedback can support explicit, field-level consent over which logs, prompts, files, and metadata are submitted.

Suggested Product Changes

• Add Acknowledge and continue and Report false positive actions to security interruptions in both Desktop and CLI surfaces.
• Display an incident or request identifier on every safety modal.
• Preserve cleared safety events in session history and CLI logs.
• Show whether the backend is paused, cancelled, or still running.
• Add a configurable review-loop budget.
• Add a terminal-equivalent “direct execution” mode that keeps the desktop UI as a thin client.
• Allow export of a redacted diagnostic package containing timing, state transitions, retries, and safety events.
• Make checkpoint/handoff independent of optional MCP availability.
• Add a private, documented incident-submission channel with selective evidence attachment and a pre-submission data preview.

Evidence Available

Available evidence includes:

• full redacted task transcript;
• timestamps;
• explicit active execution duration;
• task and review progression;
• the exact point where the run was terminated;
• the successful manual recovery action after the security modal (continue);
• environment and workflow description;
• reporter-observed recurrence of classifier interruptions during other legitimate blue-team and control-plane-adjacent CLI work.

Unavailable evidence:

• screenshot of the cleared security modal;
• internal request or safety-event identifier.

The absence of a screenshot should not require reproduction. The reporter is willing to provide the redacted transcript and answer follow-up questions based on the original session.

Redaction Summary

The attached/public version removes or generalizes:

• personal usernames;
• machine and host names;
• home-directory paths;
• repository and project names;
• branch names;
• commit hashes;
• internal helper-script names;
• gateway addresses;
• credential formats;
• organization-specific identifiers.

The technical sequence, timing, model selection, failure modes, and user impact are preserved.

What steps can reproduce the bug?

1. Launch Codex Desktop 26.707.31428 on Windows with execution configured inside WSL2.
2. Open a repository containing legitimate blue-team or control-plane infrastructure work.
3. Start a task involving defensive security topics such as:

• credential retrieval and validation;
• MCP authentication;
• secret-handling safeguards;
• replay prevention;
• session recovery;
• installer rollback and trust validation.

1. Run the task with GPT-5.6 Sol.
2. During execution, observe whether a security interruption appears offering only:

• Learn more
• Retry with a slower model

1. Attempt to acknowledge or continue the existing task from the modal.

Observed result: the modal provided no clear acknowledgement or continue action. Closing it and manually typing continue allowed the underlying session to resume, suggesting the UI and backend task state may have become desynchronized.

A second related symptom occurred during the same workflow:

1. Continue the task using subagent-driven implementation and review.
2. Observe prolonged opaque execution with repeated review/rework cycles and limited indication of whether the delay comes from model reasoning, safety review, subagents, retries, or application orchestration.

Observed result: the task remained active for 1:55:47 and was still incomplete when manually stopped.

Reproducibility note: the security modal appears intermittent. I am not willing to intentionally rerun a costly security-sensitive task solely to reproduce it. Similar classifier interruptions have also occurred during legitimate CLI-based blue-team and control-plane-adjacent work.

What is the expected behavior?

Codex Desktop should allow legitimate blue-team and control-plane-adjacent work to continue without unnecessary interruption.

If a safety classifier is triggered, the app should:

• clearly explain that the current task has been paused;
• provide an actionable Acknowledge and continue or Report false positive option;
• preserve the current session and task state;
• clearly indicate whether backend execution is paused, cancelled, or still active;
• avoid forcing the user to retry with a different model unless continuation is genuinely unavailable;
• record a stable incident identifier for later reporting.

For long-running execution, Codex Desktop should also provide transparent progress, including the current stage, active agent, review-cycle count, retries, and whether time is being spent on model reasoning, tool execution, safety review, or queued subagents.

The same task should complete with performance reasonably comparable to Codex CLI in the same WSL2 environment, or the app should clearly explain any additional orchestration overhead.

Additional information

Affected build: Codex Desktop 26.707.31428, branded “Powered by Codex & OWL,” released 10 July 2026. Environment: Windows with execution inside WSL2. Model: GPT-5.6 Sol, Light reasoning.

The affected task was legitimate defensive engineering involving MCP authentication, short-lived credential retrieval, secret-handling safeguards, replay prevention, session recovery, configuration updates, and transactional rollback. The task spent 1:55:47 in active execution and remained incomplete when manually stopped. The security modal had already cleared, so no screenshot is available. I will not intentionally reproduce the issue because the original incident consumed nearly two hours and disrupted active work.

This is not limited to one Desktop session. Other legitimate blue-team and control-plane-adjacent tasks have triggered similar classifiers in Codex CLI, although the Desktop app makes the impact worse through opaque execution and a non-actionable modal. I have a detailed redacted incident report and task transcript. The unredacted sources contain proprietary repository, infrastructure, security, and control-plane data and cannot be posted publicly. A private, scoped evidence-submission channel with explicit control over included logs would make it possible to provide richer diagnostics safely.

Agent errored: 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

input_tokens: 51,237,719
cached_input_tokens: 50,636,032
output_tokens: 86,928
reasoning_output_tokens: 14,351
total_tokens: 51,324,647