Codex Desktop 26.513.x shows “Oops, something went wrong” while PATH CLI works; WHAM/apps and plugin discovery errors in logs

What version of the Codex App are you using (From “About Codex” dialog)?

Codex Desktop package: OpenAI.Codex_26.513.3673.0 Additional version signals from local diagnostics: - Desktop log client: Codex Desktop 26.513.31313 - Embedded CLI version recorded in a new Desktop thread: 0.131.0-alpha.9 - PATH CLI for comparison: codex-cli 0.130.0, which works normally

What subscription do you have?

x5 pro

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

After updating Codex Desktop on Windows, some existing project threads and some newly-created project threads show “Oops, something went wrong” in the Desktop UI.

The screenshot below shows the Desktop UI error state:

<img width="2370" height="1572" alt="Codex Desktop shows Oops, something went wrong in a project thread" src="https://github.com/user-attachments/assets/5ed35f61-97b0-46a0-8914-fd2560f48f5c" />

The same repositories work normally from the PATH Codex CLI. Repository state, worktree state, ACLs, project-level Codex configuration, and Windows/WSL agent selection do not appear to explain the failure.

This looks like a Desktop-only regression in the Desktop/app-server/app/plugin discovery path. The strongest local signals around the repro window are failures in wham/apps, plugin discovery, and plugin cache synchronization.

The clearest ERROR around the repro window was:

rmcp::transport::worker
HTTP request failed ...
https://chatgpt.com/backend-api/wham/apps
... when send initialized notification

The same time window also contained repeated Desktop/plugin discovery warnings:

failed to warm featured plugin ids cache ...
/backend-api/plugins/featured ...
403 Forbidden

failed to refresh curated plugin cache ...
failed to back up plugin cache entry:
Access is denied. (os error 5)

failed to load discoverable tool suggestions ...
403 Forbidden

Several plugin/skill manifests were also ignored due to validation errors, for example:

defaultPrompt too long
icon path contains ..

These failures appear to be in the global Desktop/plugin/app discovery path rather than project-local configuration.

What steps can reproduce the bug?

1. Open Codex Desktop on Windows.
2. Open an affected project thread, or create a new thread in an affected project.
3. The Desktop UI shows “Oops, something went wrong”.
4. Run the PATH Codex CLI against the same repository.
5. The PATH CLI works normally.

Repository checks were performed in read-only mode.

Two affected repositories were checked. Both repositories:

• exist on disk
• have clean git status
• use a single worktree
• are on the main branch
• have normal upstream status
• have ACL entries granting CodexSandboxUsers modify permission
• do not contain project-level .codex/config.toml
• do not contain project-level .codex/local environment
• do not contain project-level .mcp.json

One affected repository has no AGENTS.md, while another affected repository has one, so AGENTS.md does not explain the shared failure.

The global Codex config marks both projects as trusted.

What is the expected behavior?

Codex Desktop should continue loading the project/thread UI even if app/plugin/WHAM discovery fails.

If plugin discovery, tool suggestions, or curated plugin cache refresh fails with 403 Forbidden or local cache write errors, Codex Desktop should degrade gracefully and keep the project/thread usable.

Additional information

I found related issues such as #18456, #16550, #20673, #16618, #17244, and #12860, but this report appears to be a newer Desktop 26.513.x / embedded 0.131.0-alpha.9 reproduction with a clearer Desktop-vs-CLI contrast.

Why this does not look like a repository/worktree issue:

• Git status and worktree state are clean.
• The affected repositories do not contain project-level Codex/MCP configuration that would explain the failure.
• ACLs include CodexSandboxUsers permissions.
• Windows/WSL agent selection is not project-specific and is set to Windows native.
• The PATH CLI works.
• Desktop uses an embedded 0.131.0-alpha.9, while the PATH CLI is 0.130.0.

Why this looks Desktop-specific:

• PATH CLI works normally on the same machine.
• Desktop new thread metadata records embedded cli_version = 0.131.0-alpha.9.
• Desktop UI shows “Oops, something went wrong”.
• Logs around the repro window repeatedly point to wham/apps, plugin discovery, and plugin cache synchronization.
• Some backend session/tool activity can succeed even when the Desktop UI shows the error.

CODEX_HOME is %USERPROFILE%\.codex.

Desktop global state:

runCodexInWindowsSubsystemForLinux: false

I cannot provide a feedback session ID from the affected thread because the Desktop UI is blocked by this error and the in-thread feedback entry point is not reachable. I can provide sanitized logs if needed. I intentionally omitted full local paths, session IDs, and potentially sensitive log payloads from this public report.