[Windows][Desktop] Archiving a project-bound task drops projectId from list_archived_threads

Codex version

• Codex Desktop package: OpenAI.Codex 26.825.5331.0
• Desktop executable product/file version: 151.0.7922.174
• Bundled CLI: codex-cli 0.151.0-alpha.7.1

Environment

• Windows, DisplayVersion 25H2, build 26200.8875
• Local saved Git project

What happened?

Archiving a task that is correctly associated with a saved project causes the same task to be returned by list_archived_threads with projectId: null.

This loses the observable project association at the active-to-archived transition. It makes archived-task recovery and attribution unreliable even though the task ID and cwd remain stable.

Reproduction

I used a fresh, empty control task so the probe did not read or modify project files and did not run project commands:

1. Call list_projects and select an existing saved local project.
2. Create a new local task with that exact projectId, then wait until it has an addressable task ID.
3. Call list_threads. The active task is present and its projectId exactly matches the selected saved project.
4. Call set_thread_archived for that exact task with archived: true.
5. Call list_archived_threads on the same host.

Actual result

The archived listing contains the same task ID and cwd, but returns:

{"projectId": null}

Expected result

Archiving should preserve the task's saved-project association, so the archived listing should return the same non-null projectId that was visible immediately before archiving.

Evidence boundary

• The task ID, project ID, saved path, and project name are intentionally redacted.
• This was reproduced in one controlled probe on 2026-08-30; I am not claiming cross-platform or universal reproduction.
• No task content or project data was needed to reproduce it.
• Root cause is unknown. The public TUI dynamic-tool path uses the same thread_summary conversion for active and archived thread/list results and passes through Thread.project_id (list path, summary mapping). That narrows the public path but does not establish whether the loss is in app-server state, the Desktop catalog, or the App callable wrapper.

Related work

• #37021 — active local-project task can return projectId=null
• #39764 — project worktree task can initially lose and later recover project metadata
• #40935 — Desktop ignores an App Server-created thread.projectId
• #41214 — archived-task/sidebar project grouping can drift across restart
• #38940 — merged experimental app-server project APIs

Those reports are adjacent, but I did not find an existing issue for the same controlled transition: non-null while active, then null for the exact same task immediately after archive.

Start with codex-rs/tui/src/dynamic_tools.rs at the list path around lines 426-460 and the thread_summary mapping around lines 1305-1310. Trace Thread.project_id through active and archived thread/list results, then check the app-server state, Desktop catalog, and App callable wrapper for where the value is lost. Done means the same non-null projectId appears before and after archiving.