›_ Codex Issues
Codex Issues / #37024

Startup context eagerly injects inactive tool, plugin, app, and skill catalogs

Open 💬 2 comments Opened Aug 5, 2026 by relh
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

Version

  • Codex Desktop / ChatGPT macOS 26.721.81911 (5973)
  • bundled codex-cli 0.146.0
  • macOS, Apple Silicon

Problem

A fresh coding session eagerly receives a large effective startup context before task work begins. In a real session I inspected, it included:

  • complete documentation and schemas for tools that were not used
  • the full installed skill catalog from unrelated repositories
  • duplicate skill entries when the same skill was exposed by an installed plugin and a legacy global skill link
  • plugin, app, connector, and inactive-mode operating instructions regardless of whether those capabilities were invoked
  • repeated generic behavior contracts and static model-identity wording

With a large plugin installed, many skill descriptions were truncated into fragments while still consuming catalog space. Duplicate PR-workflow skills appeared once from the plugin cache and once from a global link into a source checkout.

The locally controllable duplication can be mitigated by removing the global links and keeping plugin discovery. The eager context assembly itself remains.

Reproduction

  1. Install a Codex plugin that exposes multiple skills.
  2. Also expose those skill directories through the legacy global skill directory.
  3. Open a fresh session in an unrelated repository.
  4. Inspect the effective startup prompt / available-skills section.
  5. Observe both copies of the same skills, the entire unrelated catalog, and inactive tool/plugin/app instruction layers.

Expected behavior

  • Deduplicate skills by canonical name and source identity, or surface a clear conflict with deterministic precedence.
  • Inject only concise, valid metadata needed for routing; load full skill instructions only after selection.
  • Defer detailed tool schemas and plugin/app policies until the capability is active or selected.
  • Include only the active collaboration/mode contract.
  • Derive model identity from current runtime metadata or omit it.
  • Provide startup-context size/source diagnostics so users can identify expensive layers.

Related issue

#27587 covers contradictory behavioral directives. This report is narrower: eager context assembly and missing deduplication/lazy loading.

View original on GitHub ↗

2 Comments

github-actions[bot] contributor · 23 days ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

  • #35956

Powered by Codex Action

PatrickSys · 18 days ago

I measured this across local Codex rollout histories for a 24-hour window ending 2026-08-09T13:37Z.

The automatically injected <skills_instructions> catalog appeared:

  • 427 times across 275 sessions
  • 9,485,699 exact UTF-8 bytes
  • about 2,371,425 estimated tokens
  • 5.15% of all logged text-bearing context additions in that window
  • 329 unique catalog entries

Looking only at each session's latest saved resident history, the catalog occupied 6,234,425 bytes, about 1,558,606 estimated tokens, or 6.63% of logged resident context across the same 275 sessions.

The token figures are byte-based estimates, not tokenizer counts. The byte counts, event counts, session counts, and catalog entry count are exact from the rollout files.

I kept explicit SKILL.md loads separate. Those are task-triggered reads and should not be treated as automatic catalog overhead. I also excluded agent-driven ALL_TOOLS discovery calls after finding that they had initially been grouped with catalog data.

This measurement does not include callable tool schemas that are present at runtime but absent from rollout history, so it is not a full startup-context total. It only measures the injected skill catalog that is directly visible in the saved rollout evidence.