›_ Codex Issues
Codex Issues / #38724

[Regression][macOS Desktop] Orphaned “New task” sidebar entries cannot be archived or deleted

Open 💬 2 comments Opened Aug 15, 2026 by tanjiening0328-create
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

Summary

Codex Desktop created 12 phantom sidebar entries titled New task / 新任务. The entries had voice-waveform icons and could not be opened, archived, or deleted through the normal UI.

This appears to be a recurrence or incomplete fix of #32578.

Environment

  • Platform: macOS (Apple Silicon)
  • App: Codex Desktop / ChatGPT Desktop powered by Codex
  • Date reproduced: 2026-08-15
  • Locale: Chinese

The exact app version was not available from the current diagnostic session.

Actual behavior

  1. Multiple sidebar entries named 新任务 appeared in two tightly clustered batches.
  2. The normal thread-list API did not return these entries.
  3. Attempts to archive their thread IDs returned:

No Codex thread found for threadId: <redacted>. Hosts without a readable match: local

  1. The entries therefore could not be removed through either the UI or the supported archive operation.

Local-state evidence

The 12 IDs were present in:

~/.codex/.codex-global-state.json → projectless-thread-ids

However, there were no matching rollout/session files under:

  • ~/.codex/sessions/
  • ~/.codex/archived_sessions/

This indicates the sidebar index was persisted even though task/rollout creation did not complete.

No private paths, prompts, account identifiers, or raw logs are included here.

Workaround that succeeded

  1. Back up ~/.codex/.codex-global-state.json.
  2. Remove only the 12 stale IDs from projectless-thread-ids.
  3. Validate the resulting JSON and restart/refresh Codex.

After cleanup, the stale-ID intersection count was zero.

Expected behavior

  • A sidebar entry should be committed only after its underlying thread/rollout is durable.
  • If task initialization fails, the pending sidebar entry should be rolled back.
  • Startup reconciliation should automatically prune or quarantine projectless-thread-ids that have no corresponding readable thread/rollout.
  • Archive/delete should handle orphaned sidebar records instead of returning “No Codex thread found.”

Suggested fix

Use transactional/atomic creation across thread persistence and sidebar indexing, plus a reconciliation pass that validates persisted sidebar IDs against the thread store. A safe “remove stale task reference” operation would also let the UI recover without manual JSON editing.

Related: #32578

View original on GitHub ↗

2 Comments

github-actions[bot] contributor · 13 days ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

  • #37515

Powered by Codex Action

shleder · 11 days ago

The orphaned projectless-thread-ids with no corresponding readable rollout are a useful discovery/reconciliation case for codex-rescue. I’m field-testing whether it can enumerate the durable session store without being confused by sidebar-only phantom IDs, and whether doctor stays conservative when UI/global-state references do not resolve.

If you still have a backup from before manual cleanup, could you run:

pipx install codex-rescue
codex-rescue sessions
codex-rescue doctor --latest

I’m specifically interested in whether the 12 phantom entries are ignored/quarantined rather than surfaced as recoverable sessions. Rescue should not edit .codex-global-state.json as part of this test.

Sanitized output + versions/exit codes only, please—no global-state file, rollouts/SQLite, prompts, credentials, or private paths. Repo: https://github.com/shleder/codex-rescue