Codex App: @ plugin picker stuck on 'Loading plugins...' after latest update

same issue, not sure why

@etraut-openai

I was able to patch this locally with some help from Codex. I fed it a performance trace and it traced the failure back to the plugin list path.

Specifically repeated failed requests to
https://chatgpt.com/backend-api/ps/plugins/installed?scope=WORKSPACE

On my machine that endpoint was returning 403 (and sometimes 404), which left the @ picker stuck on "Loading plugins…" instead of falling through to the locally installed plugins.

Codex thinks this is what's going on:
In addition to enumerating local installed plugins, the @ picker also looks like it's pulling in remote/marketplace-style sources including "shared-with-me". That causes the workspace catalog request above. When that request fails, the picker treats it as "still loading" rather than "remote unavailable, show what we have locally," which causes the whole list to never resolve. The plugins themselves are fine (they still show up in the + menu, the plugins area, and the cli).

Codex made the following local changes that fixed it for me

• Removed shared-with-me from the marketplace kinds used by this path.
• Made the plugin query prefer local sources.
• Made failed plugin list requests fall back to an empty list.
• Stopped hiding installed plugins while the browser / computer-use availability checks were still loading.
• Narrowed the "loading" state so remote availability probes can't trap the UI indefinitely.

tldr remote/shared plugin discovery fails, and the @ UI treats that failure as "still loading" instead of falling back to the installed local plugins

Environment:

M5 Max MacBook Pro
macOS 26.5 (25F71)
codex-cli 0.130.0
Codex App 26.513.20950 (2816)

also, downgrading to Codex App 26.506.31421 fixes it without any patching, so i'm pretty sure it's a regression in the newer build.

I can reproduce the same issue on another machine.

Environment:

Codex App: 26.513.20950 (build 2816)
Codex CLI: 0.131.0-alpha.9
macOS: 26.5 (25F71)
Architecture: arm64

Observed behavior:

Typing @ in the composer opens the mention picker, but the plugin section gets stuck at Loading plugins... / never becomes usable. The + menu can still invoke plugins, and direct plugin usage still works, so the installed plugins themselves do not appear to be broken.

Local logs show repeated plugin/list failures when the @ picker is used:

method=plugin/list errorCode=-32600
list remote plugin catalog: remote plugin catalog request to https://chatgpt.com/backend-api/ps/plugins/installed failed with status 404 Not Found: {"detail":"Not Found"}

I also inspected the current app bundle read-only. In 26.513.20950, the composer mention path appears to call the plugin query with:

additionalMarketplaceKinds: ["shared-with-me"]

Specifically, this shows up in the @ mention/plugin picker paths in the webview bundle, and the plugin hook then turns that into marketplace kinds including local plus shared-with-me.

This matches the theory above: the @ picker is trying to include a remote/shared plugin catalog, the remote request returns 404 on this account/environment, and the UI does not fall back to showing the locally installed plugins.

Additional notes:

• + menu plugin invocation still works.
• skills/list and app/list succeed in the app logs.
• Some plugin/list calls succeed, but the ones involving the remote installed catalog fail with the 404 above.
• I do not have any features.* or shared-with-me related overrides in ~/.codex/config.toml.
• This looks like a regression in 26.513.20950; the previous app version did not appear to contain the same shared-with-me path in the bundle.

Any temporary workaround to fix this bug?

It's the same problem with the Codex VS Code extension (version 26.5803.61601) on Windows 11. If Codex does not receive its plugin list, it just totally refuses to let you use the extension. Even more horrible is the fact is there is no method to retry besides closing andreopening the window. I have closed and reopened my window six times now without success, and I just wonder why anyone thought this horrible flow was a good idea.

Reproduced on Codex Desktop 26.820.7780.0 for Windows ARM64 with Codex CLI 0.149.1. The same account shows the failure in both a local Windows task and a task attached to a remote Linux host.

Two UI forms of the same failure:

• The composer menu remains on Loading plugins....
• Typing an exact installed app name after @ produces no app suggestions.

Runtime checks show that this is not an installation or remote-host discovery failure:

• Fresh local and remote app-server instances each return 29 installed account apps.
• The tested app is present with enabled=true and callable=true on both hosts.
• The apps and plugins feature gates are enabled on both hosts.
• A real tool call from that app completed successfully on the remote host.
• An explicit plugin://... mention still attaches the app tools successfully.

Desktop logging narrows the failure to the renderer:

• In the local task, plugin/installed completes successfully in about 153 ms.
• Opening the picker or typing the app name does not trigger app/installed or app/read.
• The remote task shows the same missing app-lifecycle request.
• Repeated account-settings requests also return 401 Must use workspace account for this operation. This is correlated with the failure, but I cannot prove it is the root cause.

This suggests that the composer's host-scoped account-app query is not issued or its result is not applied after task navigation, while the underlying app-server inventory and MCP execution remain healthy. No cache reset, reinstall, or host restart fixes the missing renderer query.