Dot cannot resume after safety pause: HTTP 409 “Your dot’s safety failure has changed”

ChatGPT Bugs
1

Environment

  • Windows, Codex desktop app version 26.928.4866.0.
  • Also reproduced on the ChatGPT website in Microsoft Edge on Windows.
  • Feature: Dots / “Your dot paused out of precaution”.

Bug

The dot shows the safety-pause banner, but clicking the official “Resume your dot” button fails with a generic “Something went wrong” message. Reloading the page and retrying does not restore it.

The web sidebar simultaneously shows the dot as active and offers a Pause button, while the conversation input area still shows the safety-pause banner. I previously encountered a similar failure on October 1, and it has recurred.

Expected: the supported Resume flow should either resume the dot after confirmation or identify the outstanding action that needs attention.

Actual: the normal UI flow returns HTTP 409, leaving the dot blocked.

Reproduction

  1. Open an affected dot displaying the safety-pause banner.
  2. Click “Resume your dot” in that banner.
  3. Observe the generic error and HTTP 409 response.
  4. Reload the page and repeat; the same failure occurs.

I do not yet have a minimal reproduction for the initial safety flag. This report concerns the failed recovery flow after the flag is already present.

Diagnostics (sanitized)

The request generated by the official web button is:

POST /backend-api/tbo/<redacted>/runtime/resume
Content-Type: application/json

{"clear_safety_flag":true}

Response:

{"detail":"Your dot's safety failure has changed"}

HTTP status: 409.

Latest verified retry: 2026-10-03 01:52:24.385 UTC+08:00 (Asia/Shanghai), equivalent to 2026-10-02 17:52:24.385 UTC. This was after reloading the page; both web attempts failed with the same response.

The profile response during the failure contained:

{
  "status": "active",
  "isSafetyFlagged": true,
  "safety_flag": "guardian_circuit_breaker",
  "is_paused": false
}

Earlier desktop attempts during this recurrence also logged HTTP 409 with “Your dot’s runtime is not idle” and “Orbit safety state changed”. The last desktop “runtime is not idle” entry checked was at 2026-10-03 00:35:18.368 UTC+08:00.

This suggests a conflict between the safety/recovery and runtime states, but I cannot confirm the backend cause. No safety policy or local database was modified during these checks.

Is there a supported way to recover the existing dot without deleting it? Could the team investigate why the official Resume request is rejected even after a fresh page load and with clear_safety_flag already set to true?

Account, dot, thread and turn identifiers, credentials, and private task contents are omitted from this public report.