Codex Desktop: updating a shared Business workspace plugin fails because upload-url returns 404
What version of the Codex App are you using (From “About Codex” dialog)?
26.727.6591.0
What subscription do you have?
ChatGPT Business
What platform is your computer?
Microsoft Windows NT 10.0.26200.0 x64
What issue are you seeing?
Codex Desktop cannot update an existing locally built plugin that is already shared with a ChatGPT Business workspace.
The Share dialog correctly detects that the shared version is outdated and displays Update, but selecting it consistently fails with:
save remote plugin share: remote plugin catalog request to https://chatgpt.com/backend-api/public/plugins/workspace/upload-url failed with status 404 Not Found: {"detail":"Not found"}The existing shared version remains active. The updated bundle is not published.
What steps can reproduce the bug?
- Sign in to a ChatGPT Business workspace in Codex Desktop as the workspace owner.
- Install a local plugin and share it with one or more workspace members.
- Bump the local plugin version and keep the same plugin identity/App MCP.
- Open Plugins > Created by you > the existing shared plugin.
- Open Share.
- Confirm the UI says the shared version is outdated.
- Select Update.
- Observe the 404 error above.
Reproduced multiple times, including after fully restarting Codex Desktop and switching away from and back to the Business workspace.
Example local plugin manifest version: 1.0.3.
What is the expected behavior?
Codex should request an upload URL, upload the updated plugin bundle, and update the existing remote share while preserving its plugin identity, connected App MCP, access list, and installations.
Additional information
The current client implementation intentionally POSTs to /public/plugins/workspace/upload-url before uploading the bundle:
https://github.com/openai/codex/blob/main/codex-rs/core-plugins/src/remote/share.rs
The 404 occurs before the bundle PUT, so plugin validation and upload never start. This points to a backend provisioning/route availability mismatch for the Business workspace rather than a plugin bundle validation error.
Related issue #22885 reports the same backend upload-url route returning 404 through another plugin-sharing path:
https://github.com/openai/codex/issues/22885
Official Codex feedback tracking ID:
no-active-thread-019fcdbd-60b6-7640-afd2-e97cf3cf168e
No tokens, remote plugin identifiers, plugin contents, or customer data are included.
5 Comments
Having the exact same issue on V26.803.81509.
I can reproduce with the steps here as well with a shell plugin.
Third report, and a warning about the obvious workaround.
Same underlying problem from a different angle: ChatGPT Enterprise rather than Business, and via the admin plugin catalog on macOS rather than the Codex Desktop Share dialog. So this is not Windows-specific or Business-specific.
Since there is no update action in the admin plugin catalog (upload, delete and disable only), the natural workaround for this bug is delete-then-upload. That workaround is also a dead end, and it is destructive. After deleting the published plugin, uploading the new version is refused with
A plugin named <plugin-name> already exists.The name stays reserved after deletion and did not clear over several hours. Filed separately as #39508 with the evidence.The combination is what makes this worse than it first looks:
Anyone hitting this issue and reaching for the admin catalog should know step 3 before they do step 2.
Verified before reporting: the deletion did complete (the client's own catalog cache, refetched after the delete, shows the name absent from all three scopes, including a 2929-entry global catalog), and the package identity did not change (the manifest differs from the previously accepted upload in exactly one line, the version string, with an identical file set). A workspace admin key authenticates against the analytics API but returns 401 on every plugin-management path, so there is no programmatic way to release the name.
No tokens, workspace identifiers, plugin contents, hostnames, or customer data are included.
Correction to my comment above: I said the admin-catalog workaround dead-ends. It is a delay, not a dead end. The same package uploaded successfully with no change to it, at least 57 minutes after the deletion was observably complete. Details in #39508, where I have also corrected the title.
The part of my comment that stands is the ordering. The workaround still requires deleting the working version first, and there is then a window of unknown length where the replacement cannot be published and the workspace has no published plugin. The error during that window gives no indication that waiting is the answer, so it reads as a hard failure.
So for anyone landing here from this issue: the admin catalog route does work, but expect to delete first and then wait, and do not conclude from the "already exists" error that you are permanently stuck. This issue, the broken in-place update, is still the thing worth fixing, since it is what makes the destructive route necessary at all.
@kerrhome
Deleting and recreating breaks sharing and requires all users to reinstall correct?
Confirming on Codex Desktop 26.814.41957 (ChatGPT Business).
CREATE works, only UPDATE (in-place) fails. Same auth, same endpoint, same bundle. The only difference is that the failing UPDATE branch sends plugin_id to workspace/upload-url, while CREATE omits it.
Clean test from scratch:
-CREATE 0.1.0 -> share -> remote OK (Plugin_136956...), installs fine. WORKS.
-Local bump 0.1.0 -> 0.1.1. Remote share stays 0.1.0.
-UPDATE in-place -> UI shows "shared version is outdated" + Update button -> clicking fails with: save remote plugin share: ... workspace/upload-url failed with status 404 Not Found: {"detail":"Not found"} Same 404 with "Invited only" and "Anyone with the link".
-CREATE a new share of the exact same 0.1.1 bundle -> works immediately (Plugin_1dc891...), shows 0.1.1.
So CREATE 0.1.0 and 0.1.1 both work, the bundle is valid, only UPDATE (keeping the same remotePluginId) fails, at POST /public/plugins/workspace/upload-url, before the bundle PUT.
Because CREATE succeeds twice with the same auth on my account, this is NOT the unprovisioned surface from #22885. The trigger is specifically the plugin_id field. This looks like the client shipping the in-place Update action ahead of backend support (or sending the share's Plugin_... id where the backend expects a different catalog id).
Notes: newer client doesn't help (reported on 26.727.6591.0, still fails on 26.814.41957 -> backend-side cause). Delete-then-reupload workaround is also unreliable (name stays reserved, see #39508). Only reliable path is creating a brand-new share, which loses the share identity/access list/installs.
Can someone from OpenAI confirm whether workspace/upload-url is expected to accept plugin_id for in-place updates yet?