Hi,
I’m having an issue with Codex Security when trying to create a new security scan for my GitHub repository.
Repository:
Branch: main
When I try to create the scan, I receive the following error:
Failed to save scan settings: 409: A deleted scan configuration with this ID already exists. Recover it or wait for permanent cleanup before creating a new one.
The problem is that I cannot find the deleted scan anywhere in Security → Scans. The page currently shows “No scans yet.”
I have already tried:
- Refreshing the Scans page
- Using a different/new browser session
- Looking for the previously deleted scan
- Looking for a Recover/Restore option
The deleted scan does not appear, so I have no way to recover it, but Codex Security also prevents me from creating a new scan because the deleted configuration apparently still exists in the backend.
Is there a way to:
- Recover a soft-deleted Codex Security scan configuration that no longer appears in the UI, or
- Permanently purge the deleted configuration so I can create a new scan for the repository?
I have attached a screenshot showing the exact 409 error.
Thanks.
Confirming this is still reproducible. I’m seeing the same 409 across three separate repositories in my workspace. I recreated the default Codex environments, refreshed repositories and scans, and verified each repository is on main, but every attempt to create a scan still fails with:
Failed to save scan settings: 409: A deleted scan configuration with this ID already exists. Recover it or wait for permanent cleanup before creating a new one.
The deleted configurations remain hidden from Security → Scans, and the current UI provides no restore or permanent-delete action. Resetting the local Codex Security workbench did not change the cloud-side state.
Could the Codex Security team confirm whether support can restore or permanently purge these soft-deleted configurations, and whether self-service recovery is planned? I can provide repository IDs and request IDs privately.
Update: I opened a private OpenAI Support case, and it has been escalated to a support specialist.
I also inspected the low-level network responses. For each affected repository, the repository-specific scan-configuration request returned HTTP 200 with an empty items array, while attempting to create the scan still returns the 409 saying that a deleted configuration already exists.
This confirms that the soft-deleted records are filtered at the API layer, not only hidden by the UI. The client receives no configuration ID, route hid, or deletion timestamp that would allow self-service recovery.
I supplied the repository IDs, request IDs, and diagnostic evidence privately to Support. I’ll update this thread when the backend records are restored or permanently purged.