Support workspace profiles with per-profile skills, plugins, permissions

Open 💬 2 comments Opened May 16, 2026 by m-aliozkaya

What variant of Codex are you using?

App

What feature would you like to see?

Codex currently treats skills and plugins as globally available, which makes it difficult to keep different workflows isolated. For example, when I am coding, I do not want finance, writing, or research-related skills/plugins to be considered or invoked.

<img width="717" height="170" alt="Image" src="https://github.com/user-attachments/assets/2887df2e-f159-4317-a582-bab4740cd1eb" />

There is work modes but If I need finance or something else computer use etc I don't want my code skills. Or when I coding I don't prefer Alpaca or Binance plugin in my context

<img width="776" height="657" alt="Image" src="https://github.com/user-attachments/assets/79696c77-0e26-4bac-8c00-c8db1fc9b0b6" />

Additional information

_No response_

View original on GitHub ↗

2 Comments

m-aliozkaya · 3 months ago

Cowork brings the same agentic architecture to the desktop app, designed for non-coding knowledge work. In reality I want a option for non-coding usage for Codex.

I prefer Codex over the ChatGPT web version. I also have some feedback about the terminology used across ChatGPT and Codex: the naming is not consistent between the two products.

For example:

  • Plugins = Apps (or maybe MCP servers, though I’m not completely sure)
  • In ChatGPT, we “connect apps,” but in Codex, we “install plugins”.

I think the web and Codex experiences should feel more unified, especially in terms of terminology and UX consistency.

hyeluoh · 1 month ago

Adding a more specific variant of this request: thread-level plugin/MCP profiles, selected at new-thread creation time.

Many users move between distinct Codex workflows during the day: coding, design, research, product planning, data analysis, etc. Each workflow tends to need a different set of plugins and MCP servers, but today the enabled plugin set is effectively global for every thread. That creates two awkward modes:

  • keep everything enabled, which adds unnecessary tools/context to coding threads and can slow startup or tool discovery;
  • manually enable/disable plugins when switching tasks, which becomes tedious when context-switching frequently.

A concrete UX could be:

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

Another useful variant 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 just be a named allowlist/denylist of plugins and MCP servers applied to a thread at creation time. It would not need to change how plugins work internally; it would scope which plugin/MCP capabilities are visible and initialized for that thread.

Expected 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.

This would complement the existing MCP/plugin system while making Codex Desktop feel much better for users who regularly switch between scene-based workflows.