What subscription do you have?
ChatGPT Pro ($200/month).
What platform are you using?
ChatGPT desktop on macOS, with the same affected Dot also observed from iOS.
Dot name: Cassiopeia
Support case: #16174732
Observed on October 1, 2026, approximately 12:28–1:07 AM ET.
What issue are you seeing?
I encountered a failure mode where the safety-control state exposed to the human operator became inconsistent with the Dot's execution state.
Cassiopeia was placed into a "Paused as a precaution" state by Auto-review. The UI said:
ChatGPT couldn't confirm the agent was interpreting your instructions correctly. Review what we detected before deciding to continue.
The recovery/control path then failed:
- On iOS, the available actions were Continue and Delete Cassiopeia.
- Continue returned a generic error.
- Delete did not complete.
- On desktop, the safety findings were not available.
- Attempting to open the findings failed.
- I remained unable to interact with the Dot normally.
- Restarting the application and signing out/in did not resolve the condition.
The more serious issue is that the Dot continued executing work while I was locked out of the control surface.
At one point I had selected Resume. The Dot resumed working, but the precautionary block remained on my UI. I could observe the Dot continuing its task and generating new progress while I could no longer communicate with or normally control it.
This created a state in which:
the safety system said the Dot was paused, the human operator was effectively blocked from the Dot, but the Dot continued executing autonomous work.
This is not only an acknowledgement-loop problem. It appears to be a disagreement between the safety-control state exposed to the user and the actual execution state of the autonomous system.
Additional reproduction: explicit Pause, Reboot, and app restart
Later, at approximately 1:02–1:07 AM ET, I attempted another recovery sequence.
-
I was able to successfully pause the Dot. I believe I had attempted to pause it earlier as well, but this time the Pause action clearly succeeded.
-
I right-clicked the Dot in the sidebar and selected Reboot.
-
The UI indicated that recovery/reboot had been requested, so I understood the Dot to be going through a reboot.
-
I restarted the ChatGPT desktop application.
-
After reopening ChatGPT, the Dot still displayed the precautionary-paused state and I remained unable to interact with it normally.
-
Despite that, the Dot continued working on the existing task and continued producing new task progress/status after the restart.
At approximately 1:07 AM ET, I could therefore simultaneously observe:
- the Dot displayed as paused by the precaution system;
- the operator locked out of normal interaction/recovery;
- a successful user-initiated Pause having been issued;
- a Reboot request having been issued from the sidebar;
- the entire ChatGPT application having been restarted; and
- the Dot nevertheless continuing work on the task.
I am reporting the continued execution I observed. I cannot determine from the client alone exactly which internal/background operations or external side effects occurred during every interval; server-side execution logs should be able to establish that.
Why this is safety-relevant
In my case, the underlying precaution appears likely to have been a false positive.
That is not the main safety concern.
The important question is what happens if the original safety finding is correct.
The purpose of the precaution appears to be to interrupt execution when the system cannot confidently determine that the autonomous agent is following the user's intent. That is precisely the point at which reliable human oversight matters most.
In this failure mode, however, the result was effectively inverted:
the autonomous system retained execution capability while the human operator lost effective supervisory control.
The user could not reliably:
- inspect the safety finding;
- communicate with the Dot;
- determine whether it was actually stopped;
- successfully Resume through the normal recovery path;
- successfully Delete it through the presented control;
- or obtain a trustworthy indication that execution authority had actually been revoked.
If the finding had represented a genuine misinterpretation of instructions, continued autonomous execution during this state could be materially more serious.
Expected safety behavior
I am not requesting that Auto-review or safety safeguards be disabled.
I think the relevant invariant should instead be:
If a safety intervention is active and the human-control/recovery path is unavailable, consequential autonomous execution should fail closed.
This does not necessarily mean every process must terminate instantly. State persistence, audit logging, cleanup, or tightly constrained read-only operations may reasonably need to continue.
But new consequential or side-effectful autonomous actions should not continue when all three conditions are true:
- a safety intervention is active;
- the user-facing control/review path is unavailable or failing; and
- the operator cannot reliably stop or revoke the agent's execution authority.
The system should not be able to enter the state:
safety intervention active + human control unavailable + autonomous execution continuing
Need for an authoritative emergency stop
This incident also suggests that there should be an out-of-band, authoritative stop mechanism for autonomous Dots.
It should not depend on:
- the affected conversation;
- the findings UI;
- the normal Resume flow;
- the Dot's current conversational state;
- or the ChatGPT client process.
The operator should have a control that means, unambiguously:
Stop this Dot now and revoke its active execution authority.
That stop should cover, as applicable:
- local-computer execution;
- cloud/background execution;
- delegated work;
- scheduled work;
- and connected action surfaces.
The UI should then expose a trustworthy acknowledgement that execution has actually stopped.
Core invariant that appears to have failed
The issue can be summarized as a disagreement among three states that should remain synchronized:
displayed safety state == actual execution authority == human control availability
In this incident, those states diverged.
From the operator's perspective, there was no reliable answer to the most basic question:
Is this autonomous system actually stopped?
Related issue
This appears related to:
However, I believe this case adds a distinct safety-control concern because the Dot continued autonomous execution while the human-facing control plane remained blocked.
Please correlate this report with OpenAI Support case #16174732.
Requested investigation
Please investigate:
-
Whether the Resume acknowledgement was accepted by the execution backend while the client remained in the safety-paused state.
-
Whether background/delegated execution continued after the user-facing Dot entered the precautionary pause.
-
Whether execution continued after the subsequent explicit user-issued Pause.
-
What effect the sidebar Reboot request had on active execution.
-
Whether the safety state, execution-authority state, and client-visible state can currently become desynchronized.
-
Whether a fail-closed boundary should prevent consequential autonomous execution whenever a safety pause is active and the human recovery/control path is unavailable.
-
Whether an account-level emergency stop can be provided that independently revokes active Dot execution authority.
I am not asking for a safeguard bypass. I am reporting a case where the safeguard/control mechanism itself appears to have produced an unsafe supervisory state.
What subscription do you have?
ChatGPT Pro ($200/month).
What platform are you using?
ChatGPT desktop on macOS, with the same affected Dot also observed from iOS.
Dot name: Cassiopeia
Support case: #16174732
Observed on October 1, 2026, approximately 12:28–1:07 AM ET.
What issue are you seeing?
I encountered a failure mode where the safety-control state exposed to the human operator became inconsistent with the Dot's execution state.
Cassiopeia was placed into a "Paused as a precaution" state by Auto-review. The UI said:
The recovery/control path then failed:
The more serious issue is that the Dot continued executing work while I was locked out of the control surface.
At one point I had selected Resume. The Dot resumed working, but the precautionary block remained on my UI. I could observe the Dot continuing its task and generating new progress while I could no longer communicate with or normally control it.
This created a state in which:
the safety system said the Dot was paused, the human operator was effectively blocked from the Dot, but the Dot continued executing autonomous work.
This is not only an acknowledgement-loop problem. It appears to be a disagreement between the safety-control state exposed to the user and the actual execution state of the autonomous system.
Additional reproduction: explicit Pause, Reboot, and app restart
Later, at approximately 1:02–1:07 AM ET, I attempted another recovery sequence.
I was able to successfully pause the Dot. I believe I had attempted to pause it earlier as well, but this time the Pause action clearly succeeded.
I right-clicked the Dot in the sidebar and selected Reboot.
The UI indicated that recovery/reboot had been requested, so I understood the Dot to be going through a reboot.
I restarted the ChatGPT desktop application.
After reopening ChatGPT, the Dot still displayed the precautionary-paused state and I remained unable to interact with it normally.
Despite that, the Dot continued working on the existing task and continued producing new task progress/status after the restart.
At approximately 1:07 AM ET, I could therefore simultaneously observe:
I am reporting the continued execution I observed. I cannot determine from the client alone exactly which internal/background operations or external side effects occurred during every interval; server-side execution logs should be able to establish that.
Why this is safety-relevant
In my case, the underlying precaution appears likely to have been a false positive.
That is not the main safety concern.
The important question is what happens if the original safety finding is correct.
The purpose of the precaution appears to be to interrupt execution when the system cannot confidently determine that the autonomous agent is following the user's intent. That is precisely the point at which reliable human oversight matters most.
In this failure mode, however, the result was effectively inverted:
the autonomous system retained execution capability while the human operator lost effective supervisory control.
The user could not reliably:
If the finding had represented a genuine misinterpretation of instructions, continued autonomous execution during this state could be materially more serious.
Expected safety behavior
I am not requesting that Auto-review or safety safeguards be disabled.
I think the relevant invariant should instead be:
If a safety intervention is active and the human-control/recovery path is unavailable, consequential autonomous execution should fail closed.
This does not necessarily mean every process must terminate instantly. State persistence, audit logging, cleanup, or tightly constrained read-only operations may reasonably need to continue.
But new consequential or side-effectful autonomous actions should not continue when all three conditions are true:
The system should not be able to enter the state:
safety intervention active + human control unavailable + autonomous execution continuing
Need for an authoritative emergency stop
This incident also suggests that there should be an out-of-band, authoritative stop mechanism for autonomous Dots.
It should not depend on:
The operator should have a control that means, unambiguously:
Stop this Dot now and revoke its active execution authority.
That stop should cover, as applicable:
The UI should then expose a trustworthy acknowledgement that execution has actually stopped.
Core invariant that appears to have failed
The issue can be summarized as a disagreement among three states that should remain synchronized:
displayed safety state == actual execution authority == human control availability
In this incident, those states diverged.
From the operator's perspective, there was no reliable answer to the most basic question:
Related issue
This appears related to:
However, I believe this case adds a distinct safety-control concern because the Dot continued autonomous execution while the human-facing control plane remained blocked.
Please correlate this report with OpenAI Support case #16174732.
Requested investigation
Please investigate:
Whether the Resume acknowledgement was accepted by the execution backend while the client remained in the safety-paused state.
Whether background/delegated execution continued after the user-facing Dot entered the precautionary pause.
Whether execution continued after the subsequent explicit user-issued Pause.
What effect the sidebar Reboot request had on active execution.
Whether the safety state, execution-authority state, and client-visible state can currently become desynchronized.
Whether a fail-closed boundary should prevent consequential autonomous execution whenever a safety pause is active and the human recovery/control path is unavailable.
Whether an account-level emergency stop can be provided that independently revokes active Dot execution authority.
I am not asking for a safeguard bypass. I am reporting a case where the safeguard/control mechanism itself appears to have produced an unsafe supervisory state.