Plugin Management get_app_permissions treats canonical plugin IDs as not installed

Problem

get_app_permissions documents support for a plugin ID, connector ID, platform slug, or unambiguous plugin name. For connected GitHub and Gmail, the name, slug, and connector ID return matching app-specific permission information. The canonical plugin IDs returned by get_plugin_dependencies instead return status: "not_installed" and omit app_name and app_permission.

This can make an agent report that an installed app is absent, or show only global defaults instead of its app-specific settings.

Reproduction

Prerequisite: GitHub is installed/connected and a permission read by its name succeeds. Run in Code Mode:

const data = response => {
  const inner = response.structuredContent.result ?? response.structuredContent;
  return inner.structuredContent;
};
const dependency = data(await tools.mcp__codex_apps__plugin_management_get_plugin_dependencies({
  plugin_reference: "github@openai-curated-remote"
}));
const byName = data(await tools.mcp__codex_apps__plugin_management_get_app_permissions({
  app_id: "GitHub"
}));
const byId = data(await tools.mcp__codex_apps__plugin_management_get_app_permissions({
  app_id: dependency.source_plugin_id
}));
text({
  nameStatus: byName.status,
  idStatus: byId.status,
  nameHasAppPermission: Object.hasOwn(byName, "app_permission"),
  idHasAppPermission: Object.hasOwn(byId, "app_permission")
});

The helper accommodates the separate known return-wrapper mismatch in #43132.

Observed:

{"nameStatus":"found","idStatus":"not_installed","nameHasAppPermission":true,"idHasAppPermission":false}

The GitHub canonical ID was plugin_connector_1p_1a69035c238881919c4190932b2df699, also present in the CLI marketplace inventory. The same failure reproduced for Gmail with plugin_connector_1p_95d39881713c8191931482a62d6edff9. Dependency lookup accepts these IDs and returns the same metadata as the named references. Repeated paired permission reads remained inconsistent; an independent parent agent reproduced the GitHub case.

Expected behavior

All documented references for the same plugin should resolve to the same app and permission information. Resolve canonical plugin IDs before permission lookup and add paired name/ID regression tests. If canonical plugin IDs are unsupported, reject them explicitly and correct the contract rather than classifying the app as uninstalled.

Environment and scope

Observed September 6, 2026 in Codex Code Mode, installed CLI 0.153.4, macOS 26.6.2, Plugin Management package 0.1.0. Refresh returned the same version and byte-identical package files. Hosted backend version is unknown.

Only metadata/permission reads were performed. No permission modes, account identifiers, credentials, or setting values are included.

Targeted open/closed openai/codex searches for get_app_permissions found no existing issue at the time of preparation.

Start by tracing the get_app_permissions and get_plugin_dependencies entry points and how canonical IDs are resolved against the CLI marketplace inventory. Reproduce the paired name/ID lookup for GitHub and Gmail, then add regression tests verifying equivalent app and permission results, including the documented unsupported-reference behavior if that is the contract.