›_ Codex Issues
Codex Issues / #22885

Codex Desktop 26.513.20950 composer plugin mentions hang when shared-with-me catalog returns 404

Open 💬 2 comments Opened May 15, 2026 by danielha

What happened?

In Codex Desktop, typing @ in the composer opens the mention menu, but the Plugins section stays on Loading plugins... indefinitely. File search below it still works.

This started after updating to Codex Desktop 26.513.20950 / build 2816.

Environment

  • Codex Desktop: 26.513.20950, build 2816
  • Bundled CLI: codex-cli 0.131.0-alpha.9
  • macOS
  • Auth mode: ChatGPT login

Root-cause evidence

Current app-server, using temporary CODEX_HOME variants:

  • plugin/list with marketplaceKinds: ["local"] succeeds.
  • plugin/list with marketplaceKinds: ["shared-with-me"] fails when only auth.json is present.
  • plugin/list with marketplaceKinds: ["local", "shared-with-me"] fails the same way.
  • Empty/config-only temp homes produce expected auth-required errors instead.
  • Removing installed plugin config, including openai-developers, does not fix it.

Stable failing read path:

/backend-api/ps/plugins/installed -> 404 {"detail":"Not Found"}

A supported private share/write probe fails in the same backend surface before upload:

/backend-api/public/plugins/workspace/upload-url -> 404 {"detail":"Not found"}

I also tested:

  • Fresh login/re-login
  • Reinstalling Codex
  • Rebooting macOS
  • Installing/logging into the OpenAI Developers plugin
  • forced_chatgpt_workspace_id with ChatGPT account id, user id, account-user id, default org id, and auth subject
  • Temp auth variants with tokens.account_id changed to the same plausible ids
  • Feature flags including remote_plugin, apps, tool_search, tool_suggest, and enable_mcp_apps

None made the shared catalog resolve. --disable plugins avoids the path only by removing plugins entirely, which is not a usable fix.

Version comparison

Archived official build 26.506.20924 / codex-cli 0.129.0-alpha.15 returns successfully for marketplaceKinds: ["shared-with-me"] against the same auth-only temp home. It returns an empty result instead of failing the whole plugin list.

Build archaeology also found that 26.513.20950 is the first cached official build where the composer webview passes:

{ additionalMarketplaceKinds: ["shared-with-me"] }

Expected behavior

If a remote shared/workspace plugin catalog endpoint returns 404 for an account/workspace with no shared plugins, Codex should treat it as an empty remote catalog and still render local plugins in composer mentions.

Alternatively, if the 404 means the account/workspace plugin-service surface is not provisioned, the relevant backend records/endpoints should be initialized so these paths return empty lists rather than 404.

Actual behavior

The current composer path depends on shared-with-me; when that remote catalog call fails, the Plugins mention section stays stuck on Loading plugins... forever even though local plugins are available.

Impact

This makes official/local plugin mentions unusable from the composer on the affected account/workspace, despite local plugin discovery itself working.

View original on GitHub ↗

2 Comments

danielha · 3 months ago

Likely related / same symptom as #22716 .

I dug into the app-server path and found this appears to be triggered by the new composer request for additionalMarketplaceKinds: ["shared-with-me"]. On my account/workspace, plugin/list works for local but fails for shared-with-me on:

/backend-api/ps/plugins/installed -> 404 {"detail":"Not Found"}

A private plugin share/write probe also fails on:

/backend-api/public/plugins/workspace/upload-url -> 404 {"detail":"Not found"}

So the app may need to treat shared/workspace plugin catalog 404s as an empty remote catalog and still render local plugins.

MagicGeek2 · 2 months ago

I am seeing the same class of issue after recent Codex Desktop updates.

Environment

  • macOS
  • Codex Desktop: 26.609.41114
  • Codex CLI: codex-cli 0.138.0
  • Affected plugin example: build-macos-apps@openai-curated

Symptoms

  • The Desktop plugin marketplace shows previously installed plugins as not installed.
  • Manually installing from the plugin marketplace fails or does not update the UI state.
  • The composer @ plugin picker cannot find Build MacOS Apps.
  • Other installed plugins are affected as well, not only Build MacOS Apps.
  • Local CLI state still shows the plugin as installed and enabled.

Local CLI Evidence

codex plugin list shows local plugin state is healthy:

build-macos-apps@openai-curated    installed, enabled    c6ea566d
build-web-apps@openai-curated      installed, enabled    c6ea566d
github@openai-curated              installed, enabled    c6ea566d
zotero@openai-curated              installed, enabled    c6ea566d

Running the CLI install command also succeeds:

codex plugin add build-macos-apps@openai-curated --json

Result includes:

{
  "pluginId": "build-macos-apps@openai-curated",
  "name": "build-macos-apps",
  "marketplaceName": "openai-curated",
  "version": "c6ea566d"
}

Logs

Recent logs repeatedly show remote plugin catalog / installed plugin sync failures:

WARN codex_core_plugins::manager failed to warm featured plugin ids cache
error=failed to send remote featured plugin request to https://chatgpt.com/backend-api/plugins/featured
url=https://chatgpt.com/backend-api/plugins/featured?platform=codex

WARN codex_core_plugins::manager failed to refresh remote installed plugins cache
error=failed to send remote plugin catalog request to https://chatgpt.com/backend-api/ps/plugins/installed
url=https://chatgpt.com/backend-api/ps/plugins/installed?scope=WORKSPACE

WARN codex_core_plugins::remote::remote_installed_plugin_sync remote installed plugin bundle sync failed
error=failed to send remote plugin catalog request to https://chatgpt.com/backend-api/ps/plugins/installed
url=https://chatgpt.com/backend-api/ps/plugins/installed?scope=GLOBAL&includeDownloadUrls=true

Expected Behavior

If remote installed/shared plugin catalog requests fail, the Desktop plugin UI and composer @ picker should still show locally installed/enabled plugins from the local marketplace/cache.

Actual Behavior

The local CLI can see the plugins as installed/enabled, but Desktop plugin marketplace and composer @ picker behave as if they are unavailable or not installed.

Notes

This appears similar to #22885 / #22811 / #22716. The important detail is that local plugin state is healthy while the Desktop UI path is blocked by remote catalog sync failure.