›_ Codex Issues
Codex Issues / #30913

Feature request: Thread-level plugin/MCP profiles for scene-based workflows

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

What variant of Codex are you using?

App

What feature would you like to see?

Add support for selecting a plugin/MCP profile when creating a new thread in Codex Desktop.

Many users switch between different workflows throughout the day: coding, design, research, product planning, data analysis, etc. Each workflow needs a different set of plugins and MCP servers, but today enabled plugins are effectively global for every thread.

Example workflow profiles:

Coding
- GitHub
- Filesystem
- Terminal
- Database

Design
- Figma
- Superpowers
- Browser

Research
- Browser
- Notion
- Documentation

Today users have to choose between two awkward options:

  • keep all plugins enabled, which adds unnecessary tools/context to threads that do not need them;
  • manually enable/disable plugins before switching tasks.

This becomes cumbersome for users who frequently switch between different contexts.

A possible UX:

New Thread
Plugin Profile
○ Coding
  ✓ GitHub
  ✓ Filesystem
  ✓ Terminal
  ✓ Database
○ Design
  ✓ Figma
  ✓ Superpowers
  ✓ Browser
○ Research
  ✓ Browser
  ✓ Notion
  ✓ Documentation
○ Custom...

Another useful option would be allowing the active profile to be switched from the thread toolbar before the first model request, so the thread can still start with the right tool surface without changing global plugin settings.

Conceptually, a profile could be a named allowlist/denylist of plugins and MCP servers applied at thread creation time. This would not need to change how plugins work internally; it would only scope which plugin/MCP capabilities are visible and initialized for that thread.

Benefits:

  • cleaner tool lists per workflow;
  • reduced tool/context overhead;
  • faster startup when unnecessary MCP servers are not initialized;
  • better separation between coding, design, research, and planning threads;
  • easier onboarding for teams that use different toolsets for different kinds of work.

Additional information

Related to #23083, but this request is specifically scoped to thread-level profile selection and the new-thread / before-first-request UX in Codex Desktop.

This feature would complement the existing MCP/plugin system without changing the plugin model itself. Profiles could simply specify which plugins or MCP servers are enabled for a particular thread.

View original on GitHub ↗

2 Comments

github-actions[bot] contributor · 1 month ago

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

  • #29306

Powered by Codex Action

hyeluoh · 1 month ago

Thanks for flagging #29306. I agree there is overlap in the underlying motivation: reducing unnecessary app/plugin/MCP context and avoiding global enable/disable churn.

I do not think this is a strict duplicate, though. The scope and product surface are different:

  • #29306 focuses mainly on Codex CLI / per-client app management, with commands like codex --apps ..., /mcp enable/disable, and separate CLI vs ChatGPT Web app configuration.
  • This issue focuses on Codex Desktop App thread creation UX: choosing a scene/workflow plugin profile when creating a new thread, or switching it from the thread toolbar before the first model request.

The acceptance criteria here would be more Desktop/thread-specific:

  • The New Thread flow exposes a profile picker such as Coding / Design / Research / Custom.
  • The chosen profile is stored on the thread/session, not just as a global user config toggle.
  • Only the selected profile's plugin/MCP capabilities are exposed and initialized for that thread.
  • Users can switch the active profile before the first model request without changing global plugin settings.
  • The feature supports scene-based workflows where a user moves between coding, design, research, and planning threads throughout the day.

This could absolutely share implementation pieces with #29306, especially around session-level app/tool selection and configuration layering. But the request here is specifically for a first-class Desktop UX around thread-level profile selection, so I think it is useful to track separately unless maintainers prefer to consolidate all app/MCP profile work under one umbrella issue.