Plugins rollout still leaves a separate apps surface that adds duplicate context/tool cost

Resolved 💬 2 comments Opened Mar 29, 2026 by ginishuh Closed Mar 29, 2026

What issue are you seeing?

On codex-cli 0.117.0, the plugin system appears to be the supported integration surface (plugins = stable true), but the legacy apps feature still exists as a separate toggle and can still affect tool/context surface.

In practice, I currently have to keep features.apps=false in ~/.codex/config.toml as a workaround. If apps is enabled, it reintroduces the older apps surface and increases context usage, even though plugins/MCP integrations are already present. That makes the migration feel incomplete: plugins and apps behave like overlapping surfaces rather than one replacing the other.

Current environment evidence:

$ codex --version
codex-cli 0.117.0

$ codex features list
apps     stable  false
plugins  stable  true

$ codex mcp list
serena   ... enabled
context7 ... enabled
figma    ... enabled
github   ... enabled

What steps can reproduce the bug?

  1. Use Codex CLI 0.117.0.
  2. Keep plugins/MCP integrations enabled.
  3. Observe that codex features list still shows apps as a separate feature flag, even though plugins is already enabled and stable.
  4. Run the same prompt/session twice: once with apps=false, and once with apps=true.
  5. With apps=true, the older apps surface comes back and context/token usage increases noticeably; with apps=false, that overhead disappears.

Even without doing the full A/B run, the presence of both plugins and apps as independent surfaces is already visible from codex features list.

What is the expected behavior?

If plugins are the supported replacement for apps, I would expect one of these outcomes:

  1. apps is fully removed from codex features list.
  2. apps remains only as an inert compatibility flag that does not add any extra tool/context surface.
  3. Enabling apps does not duplicate or reintroduce integration surface that plugins already cover.

In short: after the plugins rollout, there should not still be a meaningful separate apps surface that users need to manually disable to avoid extra context cost.

Additional information

  • Current workaround: keep features.apps=false.
  • This matters because it is easy for users to assume that "plugins replaced apps", while in practice the legacy apps surface can still remain active and affect token usage.
  • I am filing this as a Codex CLI issue because the behavior is visible directly in codex features list, not just in one specific plugin/MCP integration.

View original on GitHub ↗

This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗