IdeaSift

Codex users cannot safely scope plugins to each repository

Codex users want plugins enabled only in repositories where they are relevant, but plugin state is currently described as user-global. Global enablement can expose unrelated projects to unwanted behavior, while the workarounds—separate CODEXHOME directories, wrapper scripts, manual toggles, or duplicated registrations—are fragile and difficult to share with a team.

For codex developers working across multiple repositories. Mentioned from Jul 2023 to Jul 2026 on GitHub.

4 different people described this problem in 2 separate discussions.

Week of 2026-07-13: 1Week of 2026-07-20: 0Week of 2026-07-27: 0Week of 2026-08-03: 0Week of 2026-08-10: 0Week of 2026-08-17: 0Week of 2026-08-24: 0Week of 2026-08-31: 0Week of 2026-09-07: 0Week of 2026-09-14: 0Week of 2026-09-21: 0Week of 2026-09-28: 0
1 mention in the last 12 weeks
Indie fit
6.0/10
Pain
6.4/10
Frequency
5.8/10
Willingness to pay
0.0/10
Momentum
4.7/10
Who pays
Professionals
Competition
Medium
Build difficulty
Medium

What people said

Quoted word for word. Follow a link to read the whole discussion.

  1. The current workaround is to avoid global enablement and use separate CODEXHOME`s, wrapper scripts, or manual enable/disable flows. That works, but it is fragile and makes team workflows hard to adopt
    maxzyma on GitHub (openai/codex)Jul 2026Has a workaround
  2. The current workarounds are either global installation, a separate CODEXHOME` plus launcher wrapper, or expanding the plugin back into four separate repo registrations
    Ielihs on GitHub (openai/codex)Jul 2026Asked for a toolHas a workaround
Build brief

See what to build and who will buy it

  • 2 product ideas with the smallest useful version and pricing
  • 3 places to find your first customers
  • 3 more quotes from people who have this problem
  • Current workarounds, existing solutions and risks