Archived chats show a Delete button, but deletion does not work

yeah，I have the same issue just like u

“Windows에서도 재현, ~/.codex/archived_sessions 수동 삭제하면 사라짐”

Disclosure

This comment is based on a Codex Desktop issue I reproduced locally. Codex itself identified and troubleshot the local persistence state, then performed a targeted workaround deletion for an earlier affected archived chat by removing the stale local records. My role in that workaround was verification: I restarted the Codex Desktop app and the macOS host, then confirmed the affected archived chat was fully gone.

For this comment, I created a fresh, non-sensitive test thread to reproduce the same bug cleanly. I also used Codex/LLM assistance to summarize the evidence and format this GitHub comment, and I reviewed the contents before posting.

I can reproduce this on Codex Desktop for macOS with that fresh, non-sensitive test thread. I think this is the same bug, and the extra useful detail is that the UI reports success while the archived thread remains in multiple local persistence stores.

Environment

• Codex Desktop app: 26.609.41114
• App bundle version: 3888
• Bundled CLI: codex-cli 0.140.0-alpha.2
• App binary version output: Codex 149.0.7827.54
• macOS: 26.5.1 / build 25F80
• Darwin: 25.5.0 arm64
• Affected screen: Settings > Archived chats

Repro

1. Create a fresh Codex Desktop chat.
2. Use a simple test prompt:

``text
This is just an example chat to understand Codex's features and capabilities on macOS. Give me top 10 things.
``

1. Let Codex respond.
2. Archive the chat.
3. Open Settings > Archived chats.
4. Delete the archived chat.

Actual behavior

Codex shows a success toast:

Deleted 1 archived chat

But the archived row remains visible immediately afterward.
<img width="1512" height="883" alt="Image" src="https://github.com/user-attachments/assets/2ca0494e-62f7-4896-82be-5bc5ae7a4da5" />

In my repro, the still-visible row was:

• Group/project label: This Is Just An Example Chat
• Thread title: List top 10 macOS features
• Fresh repro thread id: 019ec6b3-b929-7c81-92dd-f366855b66fa

Local evidence after the delete action

The thread still exists in state_5.sqlite as archived:

sqlite3 -header -column "$HOME/.codex/sqlite/state_5.sqlite" "
SELECT id, title, archived, archived_at, created_at, updated_at, cwd, rollout_path
FROM threads
WHERE id='019ec6b3-b929-7c81-92dd-f366855b66fa';
"

Relevant output:

id                                    title                       archived  archived_at  created_at  updated_at
------------------------------------  --------------------------  --------  -----------  ----------  ----------
019ec6b3-b929-7c81-92dd-f366855b66fa  List top 10 macOS features  1         1781450256   1781450127  1781450178

Timestamp conversion:

created_utc          updated_utc          archived_utc
-------------------  -------------------  -------------------
2026-06-14 15:15:27  2026-06-14 15:16:18  2026-06-14 15:17:36

The archived session file also remains on disk:

ls -l "$HOME/.codex/archived_sessions/rollout-2026-06-14T20-45-27-019ec6b3-b929-7c81-92dd-f366855b66fa.jsonl"
wc -l "$HOME/.codex/archived_sessions/rollout-2026-06-14T20-45-27-019ec6b3-b929-7c81-92dd-f366855b66fa.jsonl"
stat -f 'size_bytes=%z mtime=%Sm' "$HOME/.codex/archived_sessions/rollout-2026-06-14T20-45-27-019ec6b3-b929-7c81-92dd-f366855b66fa.jsonl"

Output:

size_bytes=237391
line_count=57
mtime=Jun 14 20:46:18 2026

session_index.jsonl still references it:

{"id":"019ec6b3-b929-7c81-92dd-f366855b66fa","thread_name":"List top 10 macOS features","updated_at":"2026-06-14T15:15:32.710214Z"}

logs_2.sqlite still has rows for the same thread:

sqlite3 -header -column "$HOME/.codex/sqlite/logs_2.sqlite" "
SELECT COUNT(*) AS log_rows_for_thread
FROM logs
WHERE thread_id='019ec6b3-b929-7c81-92dd-f366855b66fa';
"

Output:

log_rows_for_thread
-------------------
1000

Codex also checked .codex-global-state.json without dumping the full file, because it can contain unrelated prompt history. The affected thread id still exists under heartbeat-thread-permissions-by-id in both .codex-global-state.json and .codex-global-state.json.bak.

Workaround that removed an earlier affected archived chat

I did not apply this cleanup to the fresh repro thread above, so that repro evidence remains intact. However, Codex used the same cleanup logic on an earlier affected archived chat on my machine. After Codex removed the stale records, I restarted both Codex and macOS and verified that the earlier archived chat was fully gone.

This is the workaround cleanup logic, parameterized by THREAD_ID. It is not an official fix; it is included only to show which local persistence stores had to be reconciled before the archived chat actually disappeared.

set -euo pipefail

THREAD_ID="replace-with-affected-thread-id"
STATE_DB="$HOME/.codex/sqlite/state_5.sqlite"
LOGS_DB="$HOME/.codex/sqlite/logs_2.sqlite"
SESSION_INDEX="$HOME/.codex/session_index.jsonl"
GLOBAL_STATE="$HOME/.codex/.codex-global-state.json"
GLOBAL_STATE_BAK="$HOME/.codex/.codex-global-state.json.bak"

# Capture the rollout path before deleting the thread row.
ARCHIVE_FILE="$(
  sqlite3 "$STATE_DB" "
    SELECT rollout_path
    FROM threads
    WHERE id='$THREAD_ID';
  "
)"

sqlite3 "$STATE_DB" "
  PRAGMA busy_timeout=5000;
  PRAGMA foreign_keys=ON;
  BEGIN IMMEDIATE;
  DELETE FROM thread_dynamic_tools WHERE thread_id='$THREAD_ID';
  DELETE FROM thread_spawn_edges
    WHERE parent_thread_id='$THREAD_ID'
       OR child_thread_id='$THREAD_ID';
  DELETE FROM threads WHERE id='$THREAD_ID';
  COMMIT;
"

sqlite3 "$LOGS_DB" "
  PRAGMA busy_timeout=5000;
  BEGIN IMMEDIATE;
  DELETE FROM logs WHERE thread_id='$THREAD_ID';
  COMMIT;
"

if [ -f "$SESSION_INDEX" ]; then
  tmp="$(mktemp)"
  awk -v id="$THREAD_ID" 'index($0, id) == 0 { print }' "$SESSION_INDEX" > "$tmp"
  chmod 0644 "$tmp"
  mv "$tmp" "$SESSION_INDEX"
fi

for p in "$GLOBAL_STATE" "$GLOBAL_STATE_BAK"; do
  if [ -f "$p" ]; then
    tmp="$(mktemp)"
    jq -c --arg id "$THREAD_ID" '
      .["electron-persisted-atom-state"]["prompt-history"] |= del(.[$id])
      | .["electron-persisted-atom-state"]["heartbeat-thread-permissions-by-id"] |= del(.[$id])
      | .["electron-persisted-atom-state"]["projectless-thread-ids"] |= ((. // []) | map(select(. != $id)))
      | .["electron-persisted-atom-state"]["thread-workspace-root-hints"] |= del(.[$id])
      | .["electron-persisted-atom-state"]["thread-projectless-output-directories"] |= del(.[$id])
    ' "$p" > "$tmp"
    chmod 0644 "$tmp"
    mv "$tmp" "$p"
  fi
done

if [ -n "${ARCHIVE_FILE:-}" ] && [ -f "$ARCHIVE_FILE" ]; then
  rm -f "$ARCHIVE_FILE"
fi

Interpretation

This looks like the delete handler either:

• shows an optimistic success toast before persistence updates actually succeed, or
• deletes from one backing store but leaves other stores that can rehydrate the archived-thread UI.

The stores that remained involved in this repro were:

• ~/.codex/sqlite/state_5.sqlite
• ~/.codex/sqlite/logs_2.sqlite
• ~/.codex/session_index.jsonl
• ~/.codex/archived_sessions/*.jsonl
• ~/.codex/.codex-global-state.json
• ~/.codex/.codex-global-state.json.bak

Expected behavior: after the delete action succeeds, the archived row should disappear and should not remain as archived = 1 in local thread state.

Adding another macOS repro.

Environment:

• macOS 26.5.1 (25F80)
• Bundled CLI: codex-cli 0.140.0-alpha.2
• Local thread state source: ~/.codex/sqlite/state_5.sqlite

Observed behavior:

• An archived chat could not be removed from the desktop UI.
• The affected thread still had archived = 1 in threads after the UI-side delete attempt.
• The same thread was still referenced by ~/.codex/session_index.jsonl.
• The archived rollout file still existed under ~/.codex/archived_sessions/.
• Related log rows and persisted app-state entries also remained for the same thread id.

Expected behavior:

• When the archived-chat Delete action reports success, the archived row should disappear and the local persistence stores should be reconciled.
• If permanent deletion is not supported yet, the archived screen should not show an active Delete action.

Workaround used locally:

• Back up the local Codex state files.
• Remove the archived thread row and related local references from the local state stores.
• Remove the corresponding archived rollout file.

This matches the behavior described in this issue: the UI exposes deletion for archived chats, but the archived chat remains in local persistence afterward.

This still happens in the latest build 26.609.71450.

Adding another Windows reproduction.

Environment

• Platform: Windows
• OS: Windows 11 Education, version 25H2, build 26200.8457, 64-bit
• Codex Desktop package: OpenAI.Codex
• Package version: 26.609.9530.0
• Package full name: OpenAI.Codex_26.609.9530.0_x64__2p2nqsd0c76g0
• Codex CLI: codex-cli 0.118.0
• UI locale: Korean
• Affected screen: Settings > Archived chats

Reproduction Steps

1. Open Codex Desktop.
2. Archive an existing chat/thread.
3. Open Settings > Archived chats.
4. Click the trash/delete button for an archived chat.
5. Codex shows a localized success toast indicating that the archived chat was deleted.
6. The archived chat still remains visible, or appears again after returning to the archived chats screen.

Actual Behavior

The UI reports that the archived chat was deleted, but the archived chat is not actually removed.

Expected Behavior

If deletion is supported, the archived chat should be removed and should not reappear.

If deletion is not supported yet, the UI should not show a successful deletion message. It should show a clear error, or disable/hide the delete action instead.

Notes

I am intentionally not including local thread IDs, local file paths, screenshots, or chat contents that may contain private workspace/chat information.

I have not attempted any manual local-state cleanup. A supported fix or documented safe cleanup method would be helpful.

why this issue still exists in the new version？

Disclosure: This follow-up was drafted with Codex from my direct user experience. Codex performed the local troubleshooting and cleanup checks; I reviewed the results. My role here was to verify the visible outcome in the Codex Desktop app and macOS host after restart.

Additional finding: archived chat deletion also appears to leave stale config.toml state behind.

After the archived-chat deletion problem and manual cleanup, Codex found that my local ~/.codex/config.toml still contained trusted project entries for workspaces that no longer existed. The relevant shape was:

[projects."/Users/<user>/Documents/Codex/2026-06-14/this-is-just-an-example-chat"]
trust_level = "trusted"

That this-is-just-an-example-chat workspace was the clean reproduction chat created for this issue. It had already been deleted from the archived chat store and local filesystem, but the corresponding project trust entry remained in config.toml.

Codex then checked all [projects.*] entries in ~/.codex/config.toml against the filesystem and found multiple stale trust entries whose directories no longer existed. Some were from previously deleted archived/projectless Codex chats. After removing those stale blocks, validation showed:

toml_valid=yes
project_trust_entries=15
missing_project_trust_entries=0

This looks like a second residue path from the same deletion bug:

1. Archived chat deletion can report success while the archived chat remains visible.
2. Manual cleanup can remove the archived session DB/index/log/global-state records and workspace directory.
3. But ~/.codex/config.toml can still retain [projects."<deleted workspace>"] trust_level = "trusted" entries for deleted archived/projectless chat workspaces.

I am not claiming the stale config.toml entry is what keeps the archived chat visible in the UI. It may be a separate leftover. But it is still persistent local state associated with deleted archived chats, and it means "delete archived chat" does not fully clean the local Codex instance.

Suggested implementation consideration:

• When deleting an archived projectless chat whose auto-created workspace is also removed, also remove the matching [projects."<cwd>"] trust entry from ~/.codex/config.toml.
• Avoid leaving trusted project entries for workspaces that no longer exist.

This seems to be fixed by the latest build 26.611.61049.

In the latest version ,this issue has been corrected!

The latest version has been fixed

Confirming this is fixed for me after updating Codex Desktop.

On Windows, this works correctly again in Codex version 26.611.8273.0.