Project-scoped Work/Codex environments instead of app-global or session-derived mode

Open 💬 0 comments Opened Aug 26, 2026 by EolaFam1828

What Version / Platform am I using:

ChatGPT
Powered by Codex & OWL
Version 26.820.60940
Released Aug 25, 2026
© OpenAI

Issue Summary:

The unified ChatGPT desktop app currently appears to scope the ChatGPT vs. Codex environment globally at the application level, rather than persist the intended environment as part of each local project/workspace.

This creates a particularly confusing workflow when the same desktop app contains multiple unrelated local folders that are intentionally used for different kinds of work.

For example:

Project Name: 'My-Daily-Work' is a non-code knowledge-work based professional workspace that I primarily _intend_ to use with _ChatGPT Work_.
Project Name: 'My-HomeLab' is a GitHub repository and software project that I primarily _intend_ to use with _Codex_.

These should be able to coexist as independently configured projects. Instead, switching between ChatGPT and Codex changes the operating environment for the application while retaining the currently selected project underneath it. The result is situations like:

Codex → My-Daily-Work → "What should we build in My-Daily-Work?"

That folder is not a software project. I did not select Codex because I wanted Codex to reinterpret that folder. I selected Codex because I wanted to work on a different project that is actually a code repository.

Expected Behavior

The project should own its default execution environment. For example:

My-Daily-Work
Environment: ChatGPT Work
Repository: No
Local folder: Yes
Remote access: Yes

My-HomeLab
Environment: Codex
Repository: Yes
Git repository: Yes
Local folder: Yes
Remote access: Yes

When I select My-Daily-Work, the application should enter its configured Work environment. When I select My-HomeLab, the application should enter its configured Codex environment. A conversation-level override could still exist for cases where a user intentionally wants to open a project with another environment.

The important distinction is:

Current apparent model:
Application
↓
ChatGPT or Codex
↓
Project

versus my Desired model:
Application
↓
Project
↓
Default environment: Work or Codex

The project should be the durable object. ChatGPT, Work, Codex, Desktop, and Remote should be interfaces into that project.

Current desktop behavior

A reproducible example:

Open the unified ChatGPT desktop application.
Select a local folder used as a ChatGPT Work project.
Use that project normally through Work.
Use the global ChatGPT/Codex selector and switch to Codex.
The same project remains selected.
Codex now interprets that non-code workspace through the Codex environment.

In my case the UI literally changes from a normal Work workspace into:

"What should we build in My-Daily-Work?"

This exposes the implementation hierarchy directly to the user. Switching the application environment should not implicitly reinterpret the currently selected project.

Remote/iOS makes the problem more obvious. A local folder that I normally use through ChatGPT Work is still accessible through Remote. So remote access to the folder itself is clearly possible. However, Remote appears to enter that workspace through the Codex execution environment. For a non-Git Work folder, Codex then has to reason about facts such as:

there is no .git directory
this is not a Git repository
repository-specific behavior may not apply
the workspace should not necessarily be treated as a software project

It can eventually infer those things, but it remains operating through the Codex environment. This means the application is repeatedly using model reasoning to rediscover workspace properties that should already be persistent project metadata. Whether a workspace is a Git repository should not need to be inferred every time the workspace is opened through another client. More importantly, the intended environment of that workspace should not change based on whether I entered it from Desktop Work, Desktop Codex, or iOS Remote.

### Why this matters

This is more than a navigation preference. Users can have fundamentally different local projects on the same machine:

Corporate/work documents:
→ ChatGPT Work

Software repository:
→ Codex

Research workspace:
→ ChatGPT Work

Infrastructure repository:
→ Codex

Those projects can require different:

system behavior
instructions
permissions
tools
Git assumptions
execution capabilities
plugins
context handling
approval policies
model defaults

Those properties logically belong to the project, not to a global application switch. The current model makes internal product boundaries visible to the user and requires the user to continually reconcile those boundaries manually.

Proposed project model

Local projects could persist metadata similar to:
Project
├── identity
├── local root
├── default environment
│ ├── ChatGPT
│ ├── Work
│ └── Codex
├── repository type / Git metadata
├── project instructions
├── permissions
├── connected tools
├── model defaults
├── remote access
└── conversation/session state

Then every client could resolve the project consistently:
Desktop
↓
My-Daily-Work
↓
Work

iOS Remote
↓
My-Daily-Work
↓
Work

and:
Desktop
↓
My-HomeLab
↓
Codex

iOS Remote
↓
My-HomeLab
↓
Codex

Suggested UX

When adding or configuring a local project:

Default environment

ChatGPT
Work
Codex

Ask each time

Optionally:
Allow environment override for individual conversations

This preserves flexibility without forcing environment selection to become global application state.

Why I think this is the correct abstraction

The unified desktop application already treats local folders as persistent projects and can expose those projects through multiple surfaces. Remote can also access those local workspaces. That means the project already has a durable identity independent of a single conversation. The missing piece appears to be making the project's execution environment and workspace semantics equally durable. Right now the product surface seems to determine how the workspace is interpreted. I believe that relationship should be inverted:

The project should determine its default environment. The client should simply provide access to that project. This would make mixed Work/Codex workflows substantially more coherent without requiring the two environments themselves to be merged.

View original on GitHub ↗