Sites Plugin Broken - won't re-auth on reinstall

I’m seeing the same issue on Windows with Codex Desktop.

Environment:

• Codex Desktop on Windows
• Sites connector: connector_20205bf7d4e99a89d7154bb849718324
• Sites plugin: plugin://sites@openai-bundled
• Share page currently says Sites is unavailable:

https://chatgpt.com/plugins/share/sites

Observed behavior:

• @sites / plugin://sites@openai-bundled often does not expose the mcp__codex_apps__sites namespace.
• app://connector_20205bf7d4e99a89d7154bb849718324 also often does not bind the Sites tools.
• When the tools briefly appear in tool discovery, backend calls intermittently fail with Unknown tool errors, for example:

Mcp error: -32001: Unknown tool({"name":"sites.get_site"})
Mcp error: -32001: Unknown tool({"name":"sites.list_site_versions"})
Mcp error: -32001: Unknown tool({"name":"sites.get_deployment_status"})

Impact:

• Existing deployed Sites remain live.
• Saving/deploying new versions and reading deployment status are not possible.
• Restarting the laptop and starting new Codex threads did not resolve it.

This appears to be the same Sites connector/toolbinding issue, and it is reproducible on Windows as well.

I reproduced the same Sites connector failure on Windows.

Environment:

• Codex desktop app: 26.707.30751
• Windows
• Sites plugin: 0.1.10
• Connector: connector_20205bf7d4e99a89d7154bb849718324

Additional evidence:

• sites@openai-bundled is installed and enabled in config.toml.
• The plugin's .app.json points to the expected connector.
• The codex_apps ListTools response advertises 19 Sites operations, including sites.list_sites, sites.save_site_version, and sites.deploy_site_version.
• Valid, identical read-only calls to sites.list_sites({ limit: 1 }) are inconsistent: three returned MCP -32001 Unknown tool({"name":"sites.list_sites"}), while one returned Action completed.
• In the original long-running turn, the projected tool set contained no Sites tools. A later turn exposed all 19, but execution still failed intermittently.
• I found no authentication, entitlement, connector-startup, or network failure in the local logs.
• The Sites plugin manifest lacks "required": true, unlike the current GitHub and Gmail connector manifests. This may contribute to activation/projection instability, though the stronger confirmed symptom is the ListTools/CallTool registry mismatch.

This looks like an inconsistent discovery/execution registry (possibly different backend/router instances holding different connector catalogs), rather than a missing local installation or ordinary authentication failure.

Same thing.

Environment:

Codex Desktop on Windows
Sites connector: connector_20205bf7d4e99a89d7154bb849718324
Sites plugin: plugin://sites@openai-bundled
Share page currently says Sites is unavailable:
https://chatgpt.com/plugins/share/sites
Observed behavior:

https://github.com/sites / plugin://sites@openai-bundled often does not expose the mcp__codex_apps__sites namespace.
app://connector_20205bf7d4e99a89d7154bb849718324 also often does not bind the Sites tools.
When the tools briefly appear in tool discovery, backend calls intermittently fail with Unknown tool errors, for example:
Mcp error: -32001: Unknown tool({"name":"sites.get_site"})
Mcp error: -32001: Unknown tool({"name":"sites.list_site_versions"})
Mcp error: -32001: Unknown tool({"name":"sites.get_deployment_status"})

I reproduced a related but more specific Sites account-switch/auth-routing failure on macOS.

Environment

• macOS (Apple Silicon)
• Codex CLI: 0.144.5
• Sites plugin: 0.1.27
• Sites connector: connector_20205bf7d4e99a89d7154bb849718324

Observed behavior

• Codex itself is authenticated to Account B (new account).
• The Sites UI can show Connected, but read-only sites.list_sites still returns four projects and access policies belonging to Account A (previous account).
• Every returned allowed_users entry points only to Account A.
• The plugin-management backend simultaneously reported the Sites connector as not installed, despite the UI showing it as connected.
• This looks like the Sites connector retaining or routing through a stale server-side account/link after an account switch.

Recovery attempts that did not fix it

1. Removed and re-added sites@openai-bundled.
2. Disconnected/reconnected Sites while signed into Account B.
3. Moved aside all local discovery caches:

• ~/.codex/cache/codex_apps_tools/*.json
• ~/.codex/cache/codex_app_directory/*.json
• ~/.codex/cache/codex_apps_server_info/*.json

1. Retried from a fresh thread.
2. Started a separate ephemeral codex exec process and called only sites.list_sites.

The fresh process still returned Account A's Sites data, so this is not limited to an in-memory thread or an old local cache.

Fresh reproduction session

• 019f6baf-79c4-78c2-b816-a8095c96244d

No Sites create/update/save/deploy calls were made during verification.

Expected
After reconnecting Sites while Codex is authenticated to Account B, the Sites connector should create/use an Account-B-scoped link and list_sites should not expose Account A's projects or access policy.

Still reproducible for me as of July 30, 2026 (KST). The Codex Sites connector remains unavailable in Codex, so the Sites tools cannot be used. This is still unresolved on my account. Please provide a status update or a reliable workaround.

Follow-up as of July 30, 2026 (KST): this issue is still open, and there has been no maintainer update or documented workaround since the previous reports. Could the team confirm whether this is being tracked internally and share the current status, diagnostic steps, or a reliable workaround for the persistent Sites connector tool-binding / Unknown tool failures?