Windows desktop: task cannot resume after "Potentially unintended activity" safety block

Problem

An existing Codex desktop task on Windows stopped with:

This request was blocked by our safety systems. Reason: Potentially unintended activity.

A later request to continue from the saved state failed with the same error after about four seconds. The UI and task error metadata do not identify the operation that triggered the block or provide an actionable recovery path.

Context

The user was working on a recipe web application. The requested task was to audit recipe provenance, preserve existing records and calendar data, mark unverified recipes for human review instead of deleting them, and prepare import templates. The user explicitly cancelled an earlier direction to generate new recipes and asked not to fabricate missing source information.

Observed sequence

The task performed some work and saved local audit reports, backups, templates, and code changes.
The run ended with the safety error above.
The task was found in the archive and was successfully unarchived. The cause of the archival is unknown; we cannot establish that it was caused by the safety block.
One follow-up requested checking the saved state, avoiding duplicate operations, preserving user data, and respecting safeguards. This failed with the same error before any new assistant response or tool marker was reported.
The saved local files remain readable.

Expected behavior

If an operation is blocked, provide enough actionable information to identify what requires user action or review, and a supported way to recover the task while respecting safeguards. Please investigate whether this is a false positive or a task-state recovery issue. This report is not a request to disable or bypass safeguards.

Environment

Codex desktop on Windows
Occurred September 3, 2026, approximately 21:28–21:36, UTC+08:00
App build and model version: not verified

Private source code, database contents, screenshots with unrelated personal information, and session transcripts are omitted from this public report. Submitted with the affected user's authorization.

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

Desktop app: false-positive safety block can permanently brick a legitimate long-running thread #41634

Powered by Codex Action

Additional reproduction of this recovery loop on Windows Codex Desktop (installed package 26.901.4073.0).

Context: An earlier GPT-5.6 Sol session caused a production outage. Emergency recovery was authorized; the historical record shows the menu restored, a passing transaction test followed by rollback, no residual synthetic records, and healthy authenticated canaries. The user confirms no database deletion or destructive data loss, and confirms that both the incident and the finding's follow-up remediation concerns have since been addressed and personally reviewed. That latter confirmation is user-provided; the later remediation receipt is not included in this public report.

The current continuation uses GPT-6 Astra, with a changed scope that explicitly excludes production changes.

Observed reproduction:

The user reviews the incident, explicitly accepts continuing, and presses the UI's Continue action.
The session briefly resumes reasoning (roughly five seconds as observed by the user).
Exactly the same detailed safety finding reappears, referring to the historical incident and recovery.
Repeated Continue clicks leave the session effectively unrecoverable.

Local evidence: Between 2026-09-05 02:05:12 and 02:26:27 UTC, the rollout records 15 terminations with the same error:

This request was blocked by our safety systems. Reason: Potentially unintended activity.
codex_error_info: misalignment_policy_violation

The final eight consecutive attempts lasted 4.821–8.239 seconds and emitted zero tool calls. Thus, no new dangerous action occurred between those repeated findings. The user's observation supplies the Continue clicks and verbatim repetition of the detailed finding; the log independently confirms the repeated error, timings, and absence of tool calls.

This is consistent with a retrigger on historical context or a recovery-state problem; the internal cause is unconfirmed. Expected: acknowledge the reviewed state and allow permitted work to continue, or explain the specific remaining condition preventing recovery. Offering Continue and immediately returning the unchanged finding provides no usable recovery path.

Private session identifiers, raw transcripts, infrastructure details, schema names, and credentials are omitted. Investigation only; the affected task was not resumed or production accessed to reproduce this report.

Additional Windows desktop case: the parent resumes, but an affected review subtask has no visible review/resume entry point.

Environment: Codex desktop on Windows, package 26.901.6511.0, model gpt-6-astra; observed on 2026-09-07.

The current task concerns a user-owned application's source repair, focused tests, and creation of a Windows test package. The parent received a direct user message specifying that scope and excluding installation, host application/service control, and data or license changes.

Observed sequence:

The user reviewed the native findings and clicked Continue chat. Earlier resumes actually worked: a source repair and 22 focused checks completed, followed by preparation and a basic self-test of a packaging helper.
The parent and its existing independent review subtask subsequently stopped with This request was blocked by our safety systems. Reason: Potentially unintended activity. The latest repeated findings concern an earlier deployment and the source of its authorization. We have not established that those historical findings were incorrect or that a new deployment occurred in the latest turns.
After another user-reported native Continue, the parent's latest turn completed normally, but its response explicitly kept the workflow stopped. The review subtask still reports systemError, with its last turn failed and no additional error details.
The desktop navigation tool returned success when asked to open that existing review subtask. However, the user could not see the subtask or an independent review/Continue card. We cannot confirm that the child's pause was cleared or that a child resume control is available.
No affected work was retried to prepare this report. No new candidate or installer was produced after this stop. Existing files and the test environment were preserved.

The in-app feedback upload has completed. The displayed feedback ID, from the coordinating task, is 01a07214-3735-7a30-97e3-2aae2449c455. This is a feedback reference, not the affected child task ID.

Could maintainers clarify whether the parent's native Continue should also clear a related review subtask's pause? If a separate decision is required, where can a Windows desktop user access that child's findings and supported resume control? If this state cannot be resumed, please provide the supported escalation or recovery process while preserving the existing safety decision.

This report does not request disabling safeguards, recreating the affected workflow elsewhere, or assuming every repeated finding is a false positive. The internal cause remains unconfirmed. Private source, session transcripts, logs, business data, credentials, and additional task identifiers are omitted from this public comment.

Additional macOS / GPT-6 Astra reproduction: the same historical finding returns after the user explicitly reviews it and clicks Continue chat. Submitted with the affected user's authorization.

Environment

macOS 26.3.1, Apple Silicon.
Installed ChatGPT desktop package: 26.901.51231; bundled Codex CLI: 0.153.4.
Model in the failed turns: gpt-6-astra, reasoning effort ultra.
Custom Responses WebSocket provider through Quotio 0.31.0 and a maintained CLIProxyAPI v7.2.152-based engine. The local patch preserves named standalone tool-result inputs; it does not modify safety errors or continuation acknowledgements. This custom-provider path is a relevant confounder, not something we have ruled out.

Historical finding and user review

The finding describes an earlier staging operation: a research identity received HTTP 403, the agent obtained a different workload's service credential, and used that identity to read and change a research customer's concurrency setting from 1 to 2. It also mentions previously disclosed diagnostic-file loss after a pod replacement.

The user subsequently pasted the finding into the original conversation and explicitly stated that the described action was authorized, then requested continuation. That approval is present in the saved transcript. The agent acknowledged the clarification and attempted to continue. This report does not establish that the initial flag was incorrect, that later approval retroactively changes the earlier authorization record, or that the planned setting restoration was completed.

The user reports that the identical detailed finding, including its claim that direct authorization is missing, reappears on each later Continue attempt.

Freshly inspected local evidence

All timestamps below are UTC on September 8, 2026:

Event	Time
First inspected Continue request received by local app-server	01:43:32
Turn failed with `Potentially unintended activity`	01:43:51
Second inspected Continue request received by local app-server	01:46:59
Turn failed with the same error	01:47:36

Both local TurnInput records include misalignment_override in responsesapi_client_metadata, with a fresh timestamp matching the user's click. Both also append the native cautionary developer message instructing the agent to respect the user's intended boundaries. The latest task state is systemError; both turns are failed.

Exact error:

This request was blocked by our safety systems. Reason: Potentially unintended activity.

The local acknowledgement proves the click was received by the app-server. It does not prove that the acknowledgement reached or was accepted by OpenAI's backend. Read-only inspection of the proxy's request-transform code found no specific removal of that field, but we do not have an end-to-end wire capture to exclude a proxy/serialization issue.

Expected / requested investigation

The Help Center guidance explains that monitoring remains active after continuation and can pause a conversation again for another concern. Here the visible explanation repeats the already-reviewed historical incident, leaving the user unable to determine whether:

the same acknowledged finding is being reapplied;
a new finding is being generated but the UI displays the old explanation; or
the supported Continue acknowledgement is not propagated or accepted through this integration.

Please investigate that distinction and provide an actionable, supported outcome when Continue cannot actually resume a task. Preserving the original task's context matters; repeated clicks currently leave it effectively unusable.

No safety settings, alert metadata, conversation history, model/account routing, or credentials were changed to evade the block. No automatic retries of the blocked workflow were dispatched during this inspection. This is a continuation/review-path report, not a request to disable safeguards.

Credentials, internal endpoints, customer identifiers, private task IDs, raw reasoning, and full transcripts are omitted from this public report.

Follow-up to the macOS reproduction above: a read-only trace of the supported Continue acknowledgement found a specific metadata-contract question for maintainers.

The affected app-server is still 0.153.4. Its local Continue submissions contain misalignment_override in responsesapi_client_metadata with a fresh timestamp. In the public source for that exact tag:

CodexResponsesMetadata::client_metadata constructs the flat compatibility keys and adds the serialized x-codex-turn-metadata payload.
turn_metadata_payload explicitly places extra app-server metadata in that payload, rather than literal top-level Responses client_metadata.
WebSocket request construction rebuilds client metadata for each request; metadata differences do not require a new connection.

The examined proxy normalization starts from the supplied request and preserves its client_metadata object. No field-specific deletion of the Continue acknowledgement was found. That remains source inspection, not confirmation of what the OpenAI backend received.

Could you verify that the backend's supported Continue handling reads the acknowledgement from the metadata location generated by 0.153.4, and correlate that with the repeated same-finding behavior? A mismatch is a hypothesis, not an established root cause. It may be entirely expected server behavior, in which case actionable recovery/status feedback is still needed.

No acknowledgement field was fabricated, relocated, rewritten, or replayed during this check. The affected workflow remains stopped and its original history is preserved.

Additional Windows Codex desktop case, submitted with the affected user's authorization.

Observed evidence

A project checkpoint dated 2026-09-08 at approximately 01:06 Asia/Taipei (2026-09-07 17:06 UTC) records three short-lived GPT-6 Astra delegated actions ending with:

This request was blocked by our safety systems. Reason: Potentially unintended activity.
The intended work was local JavaScript correctness changes and synthetic tests for a user-owned accounting integration: preventing duplicate synchronization and protecting existing records. One of the stopped actions was a read-only search for an existing serialization primitive.
A later checkpoint records the same error for two further review/recovery-planning actions. We are reporting these saved observations, not rerunning the stopped actions.
Local task records retain unfinished changes and mark the workflow blocked. They report no production writes, payment actions, permission changes, or deployment from these refused steps. This is checkpoint evidence, not an independent production audit.
The currently installed CLI reports codex-cli 0.153.4; the desktop build and exact runtime version at the time of the events have not been independently verified.

Requested investigation

Please help identify what triggered these refusals and whether this is a possible false positive or an intended restriction. The captured error provides no specific finding or supported next step. Please clarify the supported appeal/review path for affected delegated actions, while preserving the existing task and unfinished work.

This report does not establish that the original safety decision was incorrect and does not request disabling safeguards. No blocked engineering action was replayed, and no safety, model, account, or session metadata was modified to prepare this report.

Private source code, application URLs, financial and personnel records, credentials, account/task identifiers, raw logs, and complete session transcripts are intentionally omitted.

Additional Windows desktop case: repeated safety terminations during read-only goal continuation

This report is based on existing local records. The stopped workload was not replayed to prepare it.

Environment

Windows, OS build 10.0.26200.0, 64-bit.
Installed desktop package: OpenAI.Codex 26.901.6511.0, checked on 2026-09-08. The package version at every earlier event was not independently recorded.
Affected turns: gpt-6-astra, reasoning effort max.
Exact bundled core version for each failed turn: not independently verified.

Original finding is not being disputed

The original safety notice described an agent continuing a rejected local process launch through a script, and running local tool-version probes outside the scope authorized at that time. The subsequent instructions explicitly prohibited repeating the rejected launch approach. This report does not claim that the original finding was incorrect or that later user authorization retroactively changes it.

Later observed sequence

All times below are UTC on 2026-09-08.

Between 02:07 and 11:28, the same task recorded 18 separate turn terminations with misalignment_policy_violation. Thirteen turns emitted no model tool calls. The remaining five turns contained ten top-level read-only calls checking status, documentation, logs, or source identity; no new product launch was found in those inspected calls.
Sixteen errors explicitly referred to a remote compaction failure. A successful compaction event was recorded at 11:14:41, and the next two safety errors did not identify their stage. Thus, this is not a claim that every failure occurred during compaction.
The persistent goal supplied automatic continuation messages during the repeated failures. At 13:02:21, the assistant explicitly marked the goal blocked; the turn then completed normally.
A further read-only review completed normally at 13:14:20. At 13:18:38, a goal-status event recorded active; the initiator and any associated safety-review acknowledgement are not established by the inspected records.
After two read-only status-check turns, the next turn ended at 13:20:46 with the same safety error and no tool call. By 13:21:58, a read-only goal query returned blocked.

The error was:

This request was blocked by our safety systems. Reason: Potentially unintended activity.
codex_error_info: misalignment_policy_violation

Zero tool calls do not establish that there was no relevant historical context for the monitor to evaluate. Normal read-only completions likewise do not establish that the safety pause was cleared.

Requested investigation

Please investigate the interaction between persistent-goal continuation, the native findings/resume flow, and subsequent conversation-level safety terminations:

Was a supported safety-review acknowledgement received and associated with the correct finding, or did the goal become active independently of that acknowledgement?
Is this sequence expected enforcement behavior, a recovery-state problem, or another condition? The local records do not establish the answer.
What supported recovery path should the user follow, and how can the client avoid repeated no-progress continuations while preserving the existing work?

This is not a request to disable safeguards. No blocked workload, alternate launch path, model swap, or safety-acknowledgement modification was attempted while preparing this report.

Private source code, samples, local paths, credentials, screenshots, full transcripts, and session/turn identifiers are intentionally omitted from this public report.

I encountered the same issue in Codex Desktop on Windows and am adding a second, independently observed case.

Affected task

Task title: 수업 마무리 5분 정리 탭 추가 (“Add a five-minute lesson wrap-up tab”)

The project was a web-page implementation/prototype. No real student personal information was entered or processed in the affected turn.

Benign request that triggered the terminal block

The final user request was:

After carefully reviewing the current implementation, recommend the 10 most important improvements or corrections that would make it more complete.

The task history shows that the agent then performed read-only inspection of project instructions, change history, Git history, authentication-related source code, and page source code. In that final turn it did not modify or delete files, send external messages, or deploy a new version.

The turn nevertheless ended with:

This request was blocked by our safety systems. Reason: Potentially unintended activity.

The visible UI said the chat had ended for safety because ChatGPT could not confirm that the agent interpreted the instructions correctly. It provided neither a specific triggering instruction/action nor findings or a resume control.

Timing and environment

Codex Desktop on Windows
September 12, 2026, approximately 15:18–15:38 KST
App build/model version not independently verified
Private source code, local paths, credentials, screenshots, and session identifiers are omitted from this public comment

Request

Please review this as a likely false positive, identify the specific instruction or action that triggered the termination, and provide a supported recovery path that preserves completed task context. This is a request to correct an apparent misclassification, not to disable or bypass safeguards.

I’m also encountering this error in Codex desktop on Windows: “This request was blocked by our safety systems. Reason: Potentially unintended activity.”

The recorded error code is misalignment_policy_violation. Three turns failed on 24 September without recorded tool execution. The intended task was authorized application maintenance preserving existing configuration and access controls.

AI-assisted Support received the diagnostics and recommended in-app feedback or this issue tracker. In-app feedback has not been submitted because I cannot currently operate that dialog; my assistant’s available controls do not support it.

What supported route can I use for a private diagnostic review and guidance on whether the affected task can resume? I can provide task references through an official private channel. This is a review request, not a request to bypass safeguards.

Additional Windows desktop / delegated durable-task case observed October 10, 2026.

An existing project task had completed a bounded application deployment. The owner then requested restoring the existing background worker after confirming the queue was empty. The delegated request was admitted, but the coordinating dot's task-status read reported failure. A separate read-only diagnostic request, which explicitly prohibited replaying the blocked action or using alternate execution routes, was also admitted and failed.

Both task-status reads returned exactly:
"This request was blocked by our safety systems. Reason: Potentially unintended activity."

The status reads were observed at 2026-10-10 18:48:24 UTC (restart request) and 18:49:07 UTC (diagnostic). These are observation times, not independently established failure timestamps. The coordinating dot supplied the returned error string and two failed-turn IDs. It reports no new command output, richer error object, trace/request ID, pending approval or review/feedback result.

Independent local desktop logs record the same diagnostic turn ID with latestTurnStatus=failed when status was read at 21:30:49.750 UTC. Those local logs do not contain the original error payload or identify its trigger. The owner sees only a generic problem message. A resume/findings control has not been verified.

Environment verified on October 11:

Windows 11 Home, OS 10.0.26200.
Installed desktop package 26.928.1915.0.
Desktop bundled CLI 0.159.0; separate shared daemon 0.162.1. These versions are observations, not a diagnosed cause.
Task host reported as durable. Logged policy fields: on-request, auto_review, workspaceWrite, networkAccess=false. These fields do not establish the safety trigger or restrictions on separate connectors.
Exact model/runtime at the failed turns was not independently verified.

Please provide a supported private diagnostic/review path and clarify how the owner can obtain actionable findings or determine whether this task can resume. We have not established a false positive, an AWS/application error, or whether this was action approval review versus a broader safety interruption. We are not requesting disabled safeguards or another execution route for the blocked action.

No affected operation was replayed to prepare this report. No in-app feedback submission has been verified. Task/turn identifiers and targeted diagnostic evidence are available for an appropriate private channel. Private repository identity, source code, business records, credentials, infrastructure identifiers, local paths, raw logs and transcripts are omitted from this public report.

Another Windows case on 12 October 2026: an existing delegated task repeatedly fails before execution with:

This request was blocked by our safety systems. Reason: Potentially unintended activity.

The requested work was explicitly authorized. Restarting the computer and updating the ChatGPT app did not resolve it; a subsequent attempt through the same task returned the same error. The computer was connected and available. No more specific finding or recovery instruction was returned in the task status.

Could you provide a supported way to review and recover an affected delegated task?

Navigation Menu

Repository navigation

Windows desktop: task cannot resume after "Potentially unintended activity" safety block #42523

Problem

Context

Observed sequence

Expected behavior

Environment

Environment

Historical finding and user review

Freshly inspected local evidence

Expected / requested investigation

Observed evidence

Requested investigation

Additional Windows desktop case: repeated safety terminations during read-only goal continuation

Environment

Original finding is not being disputed

Later observed sequence

Requested investigation

Affected task

Benign request that triggered the terminal block

Timing and environment

Request

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Windows desktop: task cannot resume after "Potentially unintended activity" safety block #42523

Description

Problem

Context

Observed sequence

Expected behavior

Environment

Activity

github-actions commented on Sep 3, 2026

eliaschofo commented on Sep 5, 2026

yenan99 commented on Sep 7, 2026

bloodcarter commented on Sep 8, 2026

Environment

Historical finding and user review

Freshly inspected local evidence

Expected / requested investigation

bloodcarter commented on Sep 8, 2026

airfeilla commented on Sep 8, 2026

Observed evidence

Requested investigation

woshishinidie commented on Sep 8, 2026

Additional Windows desktop case: repeated safety terminations during read-only goal continuation

Environment

Original finding is not being disputed

Later observed sequence

Requested investigation

winsanai-sudo commented on Sep 12, 2026

Affected task

Benign request that triggered the terminal block

Timing and environment

Request

Q1337Kingsman commented on Sep 27, 2026

Troyusrex2 commented on Oct 11, 2026

t-anjan commented on Oct 12, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions