codex delete can unlink rollout, return failure, and leave a stale thread row

What version of Codex CLI is running?

codex-cli 0.144.4

What subscription do you have?

ChatGPT Pro x20.

Which model were you using?

Not relevant; this occurs in the local codex delete command before any model call.

What platform is your computer?

macOS 26.5.2 (25F84), arm64.

What terminal emulator and version are you using (if applicable)?

Codex Desktop integrated shell; Codex Desktop and local app-server processes were running against the default CODEX_HOME.

Codex doctor report

Before deletion, the redacted codex doctor --json state checks were healthy:

• SQLite state integrity: OK
• active rollout files/rows: 2,286 / 2,286
• archived rollout files/rows: 877 / 877
• mismatches: 0
• missing rollout files: 0
• stale rows: 0
• rollout scan errors: 0

What issue are you seeing?

codex delete --force <UUID> can unlink the rollout file, then return an error and leave the corresponding row in state_5.sqlite.threads.

Observed CLI result:

Error: failed to delete session

The command exited with status 1. The rollout file was nevertheless gone. Opening the still-visible task from Codex Desktop then failed with:

Failed to resume chat
failed to resolve rollout path `~/.codex/sessions/.../rollout-....jsonl`: file does not exist

The stale threads row still contained the missing rollout_path, with archived=0 and is_pinned=0.

What steps can reproduce the bug?

1. Start with a valid saved session whose rollout file and state_5.sqlite.threads row are in parity. In this case the rollout was 9,852,059,554 bytes.
2. Keep Codex Desktop/app-server running against the same default CODEX_HOME.
3. Run codex delete --force <UUID>.
4. Observe exit status 1 and Error: failed to delete session.
5. Verify that the rollout file has been removed but the matching threads row remains.
6. Open the task from Codex Desktop and observe failed to resolve rollout path ... file does not exist.

The session UUID, task title, local username, repository path, and rollout contents are intentionally omitted for privacy.

What is the expected behavior?

Deletion should be atomic from the user's perspective:

• on success, remove both the rollout representation and all corresponding thread metadata, emit the deletion notification, and exit 0; or
• on failure, leave a recoverable session or complete/repair the metadata deletion automatically.

The CLI should not report a generic failure after irreversibly deleting the transcript while leaving an unopenable task in the catalog.

Additional information

This was encountered while cleaning up the unbounded session-storage growth tracked in #34337. The local store had reached 43,720,251,753 bytes across 2,286 active rollouts; the largest rollout was 9.18 GiB.

The stale row had no thread_dynamic_tools records and no parent/child thread_spawn_edges. After backing up the database and removing that one stale row manually, PRAGMA integrity_check returned ok and PRAGMA foreign_key_check returned no violations.

Start with the codex delete --force <UUID> entry point and reproduce the failure while checking the rollout file and state_5.sqlite.threads row. Trace the deletion and notification behavior, using codex doctor --json and SQLite integrity checks to verify state. Done means successful deletion removes both representations and failure leaves a recoverable session or repairs its metadata.