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_
2 Comments
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:
I think the web and Codex experiences should feel more unified, especially in terms of terminology and UX consistency.
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:
A concrete UX could be:
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:
This would complement the existing MCP/plugin system while making Codex Desktop feel much better for users who regularly switch between scene-based workflows.