Windows Desktop 26.803: config.toml is atomically truncated and existing project tasks disappear from the sidebar

What version of the Codex App are you using?

Microsoft Store package: OpenAI.Codex_26.803.5235.0_x64

What platform is your computer?

Windows 11 Enterprise LTSC, version 10.0.26100, x64.

Summary

During one incident, Codex Desktop rewrote %USERPROFILE%\.codex\config.toml from 17,845 bytes to 4,267 bytes, removing many unrelated settings. Existing local project tasks then appeared to be lost from the sidebar, although the session files, thread rows, project assignments, and conversation contents were still intact.

This looks like two related state-reconciliation failures:

1. a config processor/layer writer replaced a complete valid config with a much smaller partial config;
2. the Desktop sidebar/catalog stopped surfacing active project tasks that remained healthy in the core database.

No raw config, transcripts, databases, internal project names, task IDs, credentials, or proprietary logs are attached to this public report.

Timeline (2026-08-10, UTC+8)

• 10:05:53 — A valid edit added one MCP server section to the existing config. The successful diff was additive only; no unrelated field was removed.
• 10:12:05–10:15:18 — logs_2.sqlite repeatedly recorded activity from:
  • codex_app_server::request_processors::config_processor
  • codex_config::loader::layer_io
• 10:16:14 — config.toml was replaced/re-written in one operation and shrank from 17,845 bytes to 4,267 bytes. Many unrelated settings disappeared.
• Afterward, the selected local project remained registered, but the sidebar showed only the current task and omitted older active tasks.
• A full app restart did not restore the missing tasks.
• Restoring the config from a known-good backup survived a subsequent restart, but the sidebar task visibility problem remained.

The logs available locally do not contain the OS-level writer PID, so attribution to a specific process cannot be proven. However, no shell command or agent tool call in the incident window deleted, moved, copied over, or reset the config/session/state files.

Evidence that conversation data was not deleted

Read-only diagnostics showed:

• PRAGMA quick_check and PRAGMA integrity_check on state_5.sqlite: ok
• 63 active session rollout files and 31 archived rollout files still existed globally.
• The affected project had 23 thread rows in the core database.
• Eight top-level task assignments for the project were still present (the current task plus seven older tasks).
• At least six older top-level tasks were active/unarchived but absent from the normal sidebar.
• The project assignment metadata was correct.
• The project was registered and marked expanded.
• The missing task IDs had no persisted deleted flag.
• Direct thread reads returned the original turn history.
• Direct navigation by task ID opened the supposedly missing task successfully.
• Opening a missing task did not add it back to the ordinary list.
• Pinning the same task made it immediately appear in the sidebar. Pinning the other missing tasks made all of them visible again.

This strongly suggests a Desktop sidebar/catalog/index inconsistency, not transcript loss.

Persisted sidebar state observation

The persisted Desktop state contained:

mode=project
chatSortMode=priority
projectSortMode=priority
projectExpanded=true

The user did not intentionally select Priority mode. This is reported only as an observed persisted state value, not as a user action or proven root cause.

The official troubleshooting workaround to switch to Chronological did not explain why active assigned tasks were omitted from the project view, or why pinning forced them back into the list.

Reproduction / diagnostic sequence

The original failure is intermittent, but this sequence reproduces the visibility inconsistency on the affected profile:

1. Start Codex Desktop with an existing local project containing multiple active tasks.
2. Observe that only the current task is shown under the project.
3. Restart the application; the older active tasks remain missing.
4. Verify that the project and task assignments still exist in the core state database.
5. Read or navigate to a missing task by its ID; its history opens normally.
6. Return to the sidebar; the task is still absent from the ordinary list.
7. Pin the task through the supported app thread API.
8. The task appears immediately in the pinned list.

For the config portion:

1. Start with a valid multi-section config.toml.
2. Apply a valid additive MCP-server edit.
3. Allow the running Desktop app to process/reload configuration.
4. In the affected incident, the config was later replaced with a much smaller partial file, dropping unrelated settings.

Expected behavior

• A valid additive config edit must preserve all unrelated settings.
• Desktop config reconciliation must never replace a complete config with a partial serialization.
• Active, unarchived tasks with valid rollout files and project assignments must remain visible and searchable.
• Opening or restarting the app must not make existing project tasks appear deleted.
• If the sidebar catalog diverges from the core database, Desktop should rebuild it automatically or provide a supported “Reindex local tasks” action.

Actual behavior

• A complete config was replaced by a 4,267-byte partial config.
• Many settings disappeared at once.
• Existing active project tasks vanished from the normal sidebar despite healthy database/session state.
• Restarting did not restore them.
• Direct reads/navigation worked, and pinning forced the tasks to reappear.

Workaround used

1. Created an offline backup of the complete Codex home state.
2. Restored config.toml from a known-good backup and validated that the app could parse it.
3. Restarted Codex and verified the restored config was no longer truncated.
4. Temporarily pinned the missing active tasks so they became visible.
5. Unarchived one intentionally archived task only as part of user-requested recovery.

No direct edits were made to the conversation contents.

Related issues

This appears related to, but adds a distinct correlated config-rewrite timeline and a pinning-based visibility test beyond:

• #27178 — Windows config overwritten on restart
• #34076 — project registrations/sidebar catalog diverge from core database
• #29337 — Windows project/workspace chats missing from sidebar
• #17540 — local threads missing from sidebar/search while still present on disk
• #25463 — project threads disappear while JSONL remains readable

Questions for maintainers

1. Can config_processor or layer_io serialize only the currently loaded layer and atomically replace the full user config?
2. Is there a supported ownership/merge contract for Desktop writes to config.toml?
3. Which database/catalog is authoritative for Desktop project task visibility?
4. Why does pinning a healthy but hidden task immediately make it visible?
5. Can Desktop detect catalog drift and rebuild from state_5.sqlite plus rollout files without requiring manual state edits?
6. What minimal redacted diagnostics would be most useful for a follow-up private feedback upload?

Sanitized timestamped log excerpts and file metadata can be provided privately on request. Raw configs, databases, and transcripts are intentionally withheld because they may contain sensitive information.

Start with the named config_processor and layer_io log paths, then compare the complete and partial config states around the reported timeline. Next inspect state_5.sqlite, rollout files, project assignments, and sidebar behavior using the reproduction sequence; done means additive config changes preserve unrelated settings and healthy active assigned tasks remain visible after restart without pinning.