Summary

Codex Desktop can keep showing a stale non-empty thread title in the visible sidebar after the durable local thread metadata has already been repaired. The durable SQLite and session_index.jsonl state can contain the corrected title, but the mounted sidebar row may continue to show the older title, for example Resume thread.

This looks like a renderer-side title cache invalidation gap rather than SQLite/session-index corruption.

Environment

• Product: Codex Desktop
• App version observed locally: 26.527.31326 (bundle build 3390)
• Platform: macOS 26.4.1, arm64
• Date observed: 2026-05-31

Observed behavior

1. A local title-repair guard updates durable thread metadata in ~/.codex/state_5.sqlite and appends/repairs matching records in ~/.codex/session_index.jsonl.
2. Local verification confirms the durable thread title is corrected and SQLite integrity checks pass.
3. The visible Codex Desktop sidebar can still show the previous non-empty title for the same thread.
4. Toggling/remounting the sidebar is not sufficient when the stale cached row already has a non-empty title.

Representative local evidence, redacted:

• Thread id: <thread-id>
• Durable SQLite title: Ecobee - Resume backend and frontend review
• User-visible sidebar title remained: Resume thread
• The visible Codex embedded app-server process had ~/.codex/state_5.sqlite open, so this did not appear to be a hidden alternate database.

Expected behavior

When the authoritative listed/durable title for a thread changes, the Codex Desktop sidebar should repaint the corresponding visible row without requiring unsupported renderer-state manipulation or a full app reset.

Implementation clue from local inspection

Local inspection of the installed app bundle suggested that the recent-conversation refresh path only updates an existing cached conversation title when the cached title is empty. In pseudocode, the observed behavior looked equivalent to:

if (cached.has(conversationId)) {
  update(conversationId, item => {
    if (!item.title && listedTitle) item.title = listedTitle;
  });
  return;
}

That means a stale non-empty label such as Resume thread can survive even when the authoritative listed title differs.

A safer behavior would be to update when the authoritative title differs, for example:

if (listedTitle && item.title !== listedTitle) item.title = listedTitle;

Requested support

Any first-class supported path would solve this for local recovery tooling:

1. Make the recent-conversation refresh path overwrite stale cached titles when the authoritative listed title differs.
2. Expose a supported desktop/app-server IPC route that forwards a title update to the renderer for a specific host/thread/title.
3. Connect the visible desktop app-server to the supported title-update notification path used by the remote-control app-server, if that is intended to be the canonical route.
4. Document the supported cache invalidation path if one already exists.

Why this matters

Local recovery tooling can make durable metadata correct, but operators use the visible sidebar to resume project work. If the UI continues to display stale low-signal titles, recovery and handoff workflows remain confusing even though the underlying metadata has been repaired.

Safety note

A synthetic renderer event approach was tested locally and rejected because it interfered with active thread update streams. This report is asking for a first-class app-supported title-cache refresh/invalidation hook rather than unsupported manual renderer manipulation.