[Windows Desktop] fresh and resumed Tasks omit codex_app capability root

Codex version

OpenAI.Codex Desktop package 26.915.4065.0; embedded/running runtime 0.155.0-alpha.9.2; ChatGPT.exe ProductVersion 153.0.8010.48.

Subscription

ChatGPT account using Codex Desktop (account identifiers intentionally omitted).

Platform

Windows 11 Home 10.0.26200 build 26200.

What happened?

Native Codex Desktop Task-management tools are absent from the model-visible tool catalog in both a newly started project Task and a resumed Task. Missing operations include create_thread, list_threads, read_thread, wait_threads, handoff_thread, send_message_to_thread, set_thread_title, set_thread_archived, and sidebar/pinning operations.

This appears to be a Desktop capability-root/executor-metadata provisioning regression, not a missing provider or broken backend API.

Steps to reproduce

1. Open Codex Desktop on Windows.
2. Start a new Task over a saved project, or resume an existing Task.
3. Inspect the actual tool catalog available to the Task.
4. Observe that no native Task-management tools are present.
5. Inspect app-server telemetry for the corresponding thread/start and world-state spans.

Current fresh Task/session ID: 01a0ba0c-32cc-73a2-be4e-ceb932576681

Affected resumed Task/session ID: 01a0b669-8fdf-7011-b764-63299079ee22

Expected behavior

Desktop should inject the native codex_app capability root plus executor thread metadata into both fresh and resumed Tasks. The Task should receive the native thread-management catalog and be able to call list/read/wait/create/handoff operations subject to their normal guards.

Actual behavior

Sanitized evidence:

current fresh Task thread/start: thread_start.dynamic_tool_count=0
current fresh Task world state: selected_capability_root_count=0
affected resumed Task world state: selected_capability_root_count=0
other newly started Tasks: thread_start.dynamic_tool_count=0

The current runtime's generated protocol schema includes thread/start.dynamicTools and thread/start.selectedCapabilityRoots, with capability roots described as selected by the hosting platform.

The packaged and running codex.exe are identical:

SHA-256 BC45017E8239DC150258F69309CED9DF6BBCDF5B8E4F346DECF780AC0999E226

A read-only diagnostic launch of the bundled codex-app-tools provider returned 44 tools, including every missing Task-management operation. Calling list_threads without executor metadata produced:

Codex app tools require thread metadata from the executor.

Adding MCP _meta.threadId for the current Task made list_threads succeed. read_thread and wait_threads(timeoutMs=0) also succeeded for the affected Task. No mutating provider operation was invoked. This confirms that the Desktop pipe/provider and backend Task APIs are healthy; the failure occurs in host-to-app-server capability injection.

The current Desktop instance's text log files are zero bytes, but the read-only app-server telemetry database contains the spans above. No raw database/session file is attached to avoid account and path disclosure.

Scope and safety

• Reproduces in both a fresh project Task and a resumed Task, so it is not resume-only persisted state.
• Repeated Desktop restarts and updates did not repair it.
• SQLite databases and session JSONL were read only.
• No cache/history/Tasks/worktrees/login state were deleted or reset.
• No config, feature flag, repository, plugin state, or application data was modified.

Related issues / release note

The official changelog lists Refresh resumed thread capability roots from executors (#39746). The current behavior may be a regression or a broader Windows provisioning failure.

Closest open reports found were #43350 (macOS delegated follow-up loses selected capability roots) and #32436 (new Desktop tasks missing generic workspace tools). This reproduction is different: it affects the native codex_app Task-management capability in ordinary fresh and resumed Windows Tasks, while the provider/backend remains callable.

Start with the Desktop host path that provisions app-server thread/start requests, then compare fresh and resumed Tasks using the reported thread/start and world-state telemetry. Check how dynamicTools and selectedCapabilityRoots are populated and use the read-only codex-app-tools diagnostic as the baseline. Done means both Task types receive the codex_app catalog and thread metadata, with the existing reproduction no longer showing zero roots or tools.