[macOS / ordinary Chat] Local plugins appear in @ picker but bundled skill instructions are unavailable

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

26.908.70816 (build 9275); bundled codex-cli 0.154.0-alpha.6.2

What subscription do you have?

Personal ChatGPT account, not a managed workspace. Exact subscription tier not included.

What platform is your computer?

Darwin 24.6.0 arm64 arm; macOS 15.6 (24G84)

What issue are you seeing?

On macOS, ordinary Chat in the unified desktop app offers installed local/private-marketplace plugins in the @ picker, but the affected Chat cannot load their bundled SKILL.md instructions. The same installed skill files are readable from Codex.

This is a skill-discovery/loading report, not a report that an MCP tool or a local Node command failed. The two affected packages contain skills and optional Node helper scripts, with no MCP server declaration. The first failing step is obtaining the skill instructions; no helper execution or permission-denial error was observed in the affected Chat.

Observed:

• Both plugins appear installed/enabled and can be selected as @mentions in ordinary Chat.
• Asking that Chat to read the selected skill and identify an instruction produced a report that no corresponding skill resource URI was exposed. The Chat did not read the SKILL.md file.
• The original testing also reported the same symptom in a fresh Chat.
• Disabling a plugin in the desktop UI removes it from Chat's @ picker, even though the installed files remain on disk.
• Codex can read the same installed skill files. Read-only helper checks in Codex also succeed.

The intended use case is a personal, instruction-only skill that generates analogous questions from an uploaded problem image. It should not require MCP or local command execution merely to read and follow its instructions. No claim is being made that ordinary Chat must support every local executable. The UI should accurately communicate which local skills are usable in the current surface.

What steps can reproduce the bug?

Observed reproduction with two existing local/private-marketplace plugins:

1. Install and enable a plugin from a repo/local marketplace in the desktop app. Its compatibility manifest declares a skills directory; it has no MCP server declaration.
2. Open an ordinary Chat conversation in the same desktop app.
3. Type @ and select the installed local plugin.
4. Ask: "Read the selected skill's instructions and identify one instruction from its body. Do not run any helper script or perform the workflow. If the skill cannot be loaded, distinguish that from a script-execution failure."
5. Observe that the mention is accepted, but the affected Chat reports no accessible resource for the bundled skill and does not read its body.
6. Disable the plugin in the desktop Plugins UI, then inspect Chat's @ picker: the plugin disappears.
7. In Codex, read the installed SKILL.md from the same plugin cache: it is available.

Representative package shape (identifiers are sanitized; this is not a separately executed minimal fixture):

plugins/local-workflow/
  .codex-plugin/plugin.json
  skills/local-workflow/SKILL.md

Manifest:

{"name":"local-workflow","version":"0.1.0","skills":"./skills/"}

The observed helper scripts were never needed for step 4. A newly authored, script-free minimal fixture has not yet been installed/tested.

An additional observation: adding policy.products: ["CODEX"] to the marketplace after the plugins were already installed did not remove them from ordinary Chat's picker. This does not establish behavior for a clean installation under that policy.

Conversation IDs and private repository locations are omitted from this public report. No usage-limit failure was observed; context-window utilization was not recorded.

What is the expected behavior?

For a local plugin offered as usable in ordinary Chat, the bundled skill instructions should be loadable before the model decides whether any further tools or scripts are required.

If ordinary Chat does not support these local packages, hide them from its invocation picker or mark them unavailable with a clear explanation and an appropriate Work/Codex entry point.

Please clarify the supported behavior for personal-account local/repo skills across Chat, Work, and Codex, and the scope of marketplace policy.products. Workspace-admin publishing is not available in this personal-account workflow.

Additional information

Read-only client investigation (AI-assisted; observations and inference separated):

App version: 26.908.70816, build 9275. Bundled executable reports codex-cli 0.154.0-alpha.6.2. macOS 15.6 (24G84), Apple Silicon.

In the installed app assets:

• app-primary-4af6ed7f68d1.js: xxt/jxt obtains local plugin candidates and filters disabled installed plugins. This matches the enable/disable behavior observed in the @ picker.
• app-initial-4d7ea7f81c2d.js: A1r/xSn writes plugins.<id>.enabled via config/batchWrite, then refreshes the catalogs.
• In the same asset, Vwr builds Chat's mention-to-system-hint mapping from /system_hints and the hosted installed-plugin query. This inspected path does not merge the local marketplace catalog. aUr skips a mention without a mapping.
• Gqr builds the Chat request; the inspected path does not read and attach the local SKILL.md. A local execution target is explicitly limited to a TPP/Work conversation elsewhere in the send path.
• The Chat composer has a separate Work/TPP condition for skill suggestions; plugin picker visibility is not equivalent to skill loading.

An offline check of the extracted deployed functions, using synthetic hosted responses, returned:

Case	Result for both affected plugin identifiers
Installed + enabled candidate	Included
Installed + disabled candidate	Excluded
Local-marketplace mention, with only hosted mappings	No system hint added
Matching hosted-plugin positive control	System hint added

This supports a candidate mismatch between the local catalog used for presentation and the hosted identities used for Chat activation. It is not a capture of the affected Chat's actual /system_hints response, request payload, or backend registration state. The Chat's resource-availability statement is model self-report, not a server trace. Please confirm the intended routing before treating this as the definitive backend root cause.

The public runtime also documents that product restrictions are enforced at marketplace admission and not rechecked on every runtime load of already-admitted plugins:
https://github.com/openai/codex/blob/rust-v0.154.0-alpha.6.2/codex-rs/core-plugins/src/manager.rs#L652

Related: #37313 reports a broader ordinary-Chat visibility/runtime mismatch on Windows. This report focuses on macOS, local/private skill packages, and inability to load the instruction body before any executable is needed. It does not establish that the two reports have the same cause.

The diagnostic checks did not modify plugin/config files, and no Slack message, VPN connection, or other external workflow action was performed. No credentials or raw private logs are included. No public minimal reproducer repository is attached.

Start by reproducing the local plugin flow with the stated plugin.json and skills/.../SKILL.md shape, then inspect the mention mapping in app-initial-4d7ea7f81c2d.js and candidate filtering in app-primary-4af6ed7f68d1.js. Compare the local catalog, /system_hints, and Chat request paths, and review core-plugins/src/manager.rs for admission policy behavior. Done means the supported Chat behavior is confirmed and picker visibility matches whether bundled instructions can load.