›_ Codex Issues
Codex Issues / #38986

[Desktop regression] Auto-review Guardian threads appear as duplicate project sidebar tasks

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

What version of the Codex App are you using?

ChatGPT desktop app / Codex 26.810.52044 (build 6662).

What platform is your computer?

macOS 26.5.2 (build 25F84).

What issue are you seeing?

Internal Auto-review / Guardian conversations are being surfaced as ordinary user tasks in the Codex project sidebar.

The leaked entries appear in two forms:

  1. Raw reviewer threads whose titles begin with:
  • The following is the Codex agent history whose request action you are assessing...
  • The following is the Codex agent history added since your last approval assessment...
  1. Duplicate sidebar tasks whose titles are copied from the parent user's original prompt, so several apparently identical tasks appear under the same project.

Opening a raw entry shows the internal approval-review transcript, tool results, and the final JSON decision such as {"outcome":"allow"}. These are not user-created tasks.

Auto-review itself works and is useful. The problem is only that its internal Guardian threads are being indexed and displayed as normal project tasks.

Steps to reproduce

  1. Enable Auto-review ("帮我批准") in the Codex desktop app.
  2. Work in several local projects.
  3. Run a task that requests an approval or sandbox escalation.
  4. Allow Auto-review to assess the request.
  5. Open or refresh the project sidebar.
  6. Observe a new raw Guardian task, or a duplicate task using the parent prompt as its title.

During diagnosis, a fresh internal record was created immediately after one read-only network approval, with a title beginning with the raw Guardian review prompt. This makes the problem reproducible on the current build.

Local diagnostic evidence (sanitized)

Read-only inspection of ~/.codex/state_5.sqlite showed:

  • Normal user tasks are stored with thread_source='user'.
  • The unwanted entries are stored with thread_source='subagent'.
  • Raw entries use Guardian / Auto-review metadata, including source={"subagent":{"other":"guardian"}} and the codex-auto-review model.
  • Affected internal rows have non-empty title and preview, which allows them to enter normal sidebar queries.
  • PRAGMA integrity_check returns ok.
  • 57 active normal user tasks remained intact during diagnosis.
  • Four older internal subagent rows resurfaced as visible tasks, and one additional Guardian row was created during a controlled reproduction.
  • Auto-review remained enabled throughout.

Older completed internal rows could be archived through the supported thread archive API. However, a newly completed Guardian row can temporarily return an "active writer" error when archived. A previous DB-only archive was also not fully durable because additional old internal rollouts were indexed again later.

No raw database, rollout, prompt, local path, account information, or private project screenshot is attached because those can contain sensitive conversation content.

Expected behavior

  • Auto-review should continue reviewing approval requests normally.
  • Internal Guardian / codex-auto-review threads should be ephemeral, automatically archived, or excluded from every user-facing project/sidebar query.
  • Only the parent user task should appear in the sidebar.
  • Existing normal user tasks must remain unaffected.
  • A migration or cleanup should hide already accumulated completed Guardian threads.

Actual behavior

Internal approval-review sessions appear as ordinary project tasks across multiple projects. They create meaningless duplicates, expose raw internal review transcripts, and make the sidebar difficult to use.

Impact

  • Severe sidebar clutter across projects.
  • Duplicate task names that are indistinguishable from real work.
  • Risk of exposing internal transcripts and tool output in a user-facing surface.
  • Manual cleanup is incomplete or may need to be repeated.
  • Users may disable Auto-review even though the official feature itself is working correctly and is useful.

Related issues

  • #19822 — reported the same raw Guardian title and internal approval-review thread appearing in normal history; now closed.
  • #32588 — active Guardian rows and oversized Guardian metadata accumulating in the desktop thread store.
  • #18364 — broader macOS sidebar/session pollution and non-durable DB-only cleanup.

This appears to be a recurrence/regression specifically visible in the current macOS desktop sidebar.

View original on GitHub ↗

5 Comments

github-actions[bot] contributor · 11 days ago

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

  • #38780

Powered by Codex Action

Yussis · 11 days ago

Additional local evidence after reproducing on macOS Codex Desktop 26.810.52044 (build 6662): the shipped renderer’s ordinary recent-thread path calls thread/list / thread/search with a shared sourceKinds constant that is an empty array, while the subagent hydration path separately requests sourceKinds: ["subAgentThreadSpawn"]. In the local state DB, the leaked entries are thread_source='subagent', with Guardian rows carrying source={"subagent":{"other":"guardian"}} and usually model='codex-auto-review'. This strongly supports a missing source-kind exclusion/filter in the top-level recent/sidebar query rather than database corruption. It also explains why archiving rows once is not durable: a catalog rebuild can re-import or re-unarchive the persisted Guardian rollout.

This is the same regression class as #38780, and is consistent with #34090 / #25341. The safe product fix appears to be filtering subAgentReview, subAgentCompact, subAgentThreadSpawn, and subAgentOther out of the ordinary top-level recent list (or grouping them under the parent), while retaining them for dedicated subagent/diagnostic views.

boombx403-byte · 9 days ago

Hi @Yussis, your report looks related to a local session discovery/inventory gap rather than necessarily a lost rollout. I've released Codex Rescue Alpha5, a local read-only diagnostic tool that performs filesystem-first discovery across active and archived rollouts and cross-references SQLite/index metadata without modifying any state.

If you still have the affected local Codex directory, you can inspect it via:

pip install codex-rescue==0.1.0a5
codex-rescue sessions --json

No raw files or databases are needed. If you choose to share output, please review and sanitize any private repository paths or names first.

steven75-git · 8 days ago

Independent Windows reproduction with an additional archive-persistence failure mode.

Environment

  • Codex Desktop for Windows: 26.814.5167.0
  • Codex command runner observed during the affected sessions: 0.148.0-alpha.15
  • Windows: 10.0.26200

Observed behavior

Seven duplicate sidebar tasks appeared with the same automation-derived title. Read-only local inspection showed that all seven were internal Guardian review sessions:

  • thread_source='subagent'
  • session source equivalent to {"subagent":{"other":"guardian"}}
  • linked back to two normal user parent threads
  • no spawn-edge, dynamic-tool, or section associations for the seven affected rows

The supported thread archive operation returned success for all seven. Local state then confirmed:

  • archived=1
  • archived_at populated
  • rollout paths moved from sessions to archived_sessions

However, after fully restarting Codex Desktop, all seven duplicate tasks were still visible in the left sidebar. The sidebar's Archive/Delete actions also continued to fail for these entries.

This shows that the failure is not simply that archival did not persist. The app is rendering already-archived Guardian/subagent records, or a separate sidebar/catalog layer is retaining them without reconciling archived and thread_source.

Cleanup evidence

A narrowly scoped local cleanup removed only the seven archived subagent rows and their seven matching archived rollout files. Verification afterward showed:

  • affected DB rows remaining: 0
  • affected rollout files remaining: 0
  • both normal parent thread rows still present

No raw database, rollout content, local paths, account data, project names, or thread IDs are included.

Expected fix

Top-level sidebar queries and catalog rebuilds should exclude internal Guardian/subagent sessions regardless of whether they have a displayable title. Archiving should also immediately remove such rows from every user-facing sidebar index, and startup reconciliation should prune archived internal sessions already present in cached/catalog state.

steven75-git · 8 days ago

Windows follow-up: the ghost sidebar entries still persist after an exhaustive, verified cleanup on a newer Desktop build.

Environment

  • Codex Desktop for Windows: 26.814.5517.0
  • Codex command runner: 0.148.0-alpha.15
  • Windows: 10.0.26200

Current symptom

Several duplicate tasks with the same completed Linux-VM reminder title remain visible in the left sidebar. They are no longer useful. The sidebar Archive/Delete actions fail, and fully exiting Codex for 20-40 seconds before reopening does not remove them.

Opening one of the visible entries previously resolved to an affected Guardian-derived task ID, but the supported thread APIs reported that the thread was not loaded / no Codex thread was found, and resume reported that its rollout was not found.

Verified cleanup performed while Codex was fully exited

A narrowly scoped cleanup was performed with explicit user authorization. Post-cleanup verification showed:

  • primary local state DB: 117 Guardian rows deleted, 0 remaining
  • legacy local state DB: 6 Guardian rows deleted, 0 remaining
  • matching Guardian rollout files: 117 deleted
  • both the active and backup global-state files: 4 thread/project assignment keys, 4 heartbeat permission keys, and 1 prompt-history entry removed
  • the known affected task IDs were absent from both local task DBs and from rollout storage
  • the authenticated current-task catalog endpoint returned 0 items
  • Chromium HTTP cache was cleared and recreated; the known affected ID was no longer present there

The cleanup helper also self-deleted after reporting success. Normal user tasks were not targeted.

Result

Despite all of the above, the same duplicate tasks remain visible after repeated full application restarts.

This substantially narrows the defect: the sidebar is rendering entries from a catalog/synchronization layer that is independent of, or not reconciled with, the local SQLite stores, rollout files, persisted global state, HTTP cache, and the current-task API response. Further local deletion is unsafe because the visible entries no longer have a corresponding supported thread or known local record.

Requested product-side action

Please investigate the server-side/sidebar catalog record for these orphaned Guardian-derived entries and provide either:

  1. startup reconciliation that removes entries whose thread/rollout no longer exists, or
  2. a supported repair/delete operation for orphaned sidebar entries.

The UI should never keep rendering an undeletable task after every known backing record has been removed and the supported thread API says the task does not exist.

No local paths, account data, project names, raw conversations, or task IDs are included.