Environment Isolation in Codex for separate accounts and configs across projects and organizations

Open 💬 7 comments Opened Mar 11, 2026 by timothyTheCoder

💡 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?

Many developers use Codex across multiple contexts such as company repositories, client projects, personal projects, and open source contributions. Each of these contexts may require different authentication, configuration, tools, and agent instructions.

Currently, Codex primarily relies on a single global configuration directory (e.g. ~/.codex). This means authentication, configuration files, AGENTS.md, tools, and skills can unintentionally affect unrelated projects.

For example, a company-managed AGENTS.md or configuration may be loaded while working on a personal project, or a developer may need to switch between different accounts (e.g. a company Pro/Enterprise account and a personal Plus account). Switching accounts globally using codex logout / codex login affects all projects and interrupts workflows.

This becomes especially problematic for freelancers or developers working across multiple organizations.

Proposed Direction
Introduce environment isolation so Codex can run multiple independent environments, each with its own authentication and configuration.

Each environment would behave similarly to a separate Codex setup and could contain its own:
• authentication (login or API key)
• config.toml
• AGENTS.md
• tools / MCP configuration
• skills and other agent settings

This would prevent configuration leakage, support multiple accounts or billing contexts, and make Codex much easier to use for developers working across company, client, and personal projects.

Security and Policy Considerations
Environment isolation is not only a convenience feature but also helps enforce clearer security and policy boundaries. In many organizations, agent instructions, tools, and configuration may contain internal conventions or references to proprietary systems. If global configuration is unintentionally applied to unrelated repositories (such as personal or open source projects), this can lead to accidental leakage of internal policies, incorrect tool usage, or unexpected behavior.

Providing isolated environments would allow organizations and developers to maintain clear boundaries between corporate, client, and personal development contexts while keeping Codex configuration predictable and safe.

Summary
Environment isolation would significantly improve Codex usability for developers who work across multiple organizations or maintain both professional and personal projects. It would also provide clearer configuration and policy boundaries while reducing friction when switching contexts.

Even a minimal implementation (for example allowing Codex to run with separate configuration directories or environment-specific authentication and settings) would already solve many of these issues and could be expanded over time.

This capability would make Codex much more practical for freelancers, consultants, and developers operating in multi-organization environments.

Additional information

(update)
Note: This feature request overlaps with discussions in
https://github.com/openai/codex/issues/13447 and
https://github.com/openai/codex/issues/12029.

However, the scope here is slightly broader. Those issues primarily focus on switching accounts, while this proposal is about isolated environments, which may or may not correspond to different accounts.

In practice, developers may need multiple environments even when using the same account. For example:
• Company A – using my personal account, but with company-specific AGENTS.md, tools, and configuration
• Company B – also using my personal account, but with different agents and tools
• Personal projects – same account, but without company-specific configuration
• Company C – requires using a separate company-provided account for legal or compliance reasons

In this scenario, the ability to switch accounts alone would not fully solve the problem. What is needed is the ability to switch isolated Codex environments, where each environment can define its own authentication, configuration (config.toml), AGENTS.md, tools/MCP configuration, and other agent settings.

Account switching would then become just one aspect of environment isolation, rather than the primary mechanism.

View original on GitHub ↗

7 Comments

github-actions[bot] contributor · 4 months ago

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

#13447
#13025
#13056
#13762

Powered by Codex Action

razashariff · 4 months ago

MCPS (MCP Secure) addresses the identity side of this — each agent gets its own ECDSA P-256 cryptographic passport, so even when agents share infrastructure, their identities are cryptographically distinct. Per-message signing with unique nonces prevents cross-agent impersonation, and origin binding restricts passports to specific server URIs. Published as an IETF Internet-Draft. github.com/razashariff/mcps

burakdede · 3 months ago

Good write-up. The distinction between account switching and full environment isolation matters.

I built aisw cross-tool version to solve the auth isolation piece. Each profile is a complete CODEX_HOME directory with both auth.json and config.toml, so you get different auth and different config per profile:

~/.aisw/profiles/codex/
├── company-a/         # company-provided account + config
├── company-b/         # personal account + different settings
└── personal/

Doesn't cover per-profile AGENTS.md or MCP config yet (those live at project level). But handles your "Company C requires a separate account" case. Also works across Claude Code and Gemini CLI.

Docs: https://burakdede.github.io/aisw/

MariosPapadakis · 2 months ago

Any update on this? This has been a huge problem for me

natenjo · 2 months ago

As a workaround, I use different linux users and swich to them using e.g. "su codex_private" and "su codex_project_xx", as each has it's own ~/.codex/config.toml

I am using this in WSL on my windows machine, but in general it would be nice to have this native in codex

Ducksss · 1 month ago

I put together a candidate branch that addresses the account/config/local-state isolation side of this request:

Branch: https://github.com/Ducksss/codex/tree/PinZheng/auth-profiles-review
Compare: https://github.com/openai/codex/compare/main...Ducksss:PinZheng/auth-profiles-review?expand=1

The core behavior is --auth-profile NAME / CODEX_PROFILE=NAME, with each profile using $CODEX_HOME/profiles/NAME as its own Codex home. That isolates stored auth, config overlays, sessions, logs, MCP/plugin state, daemon/socket state, feature flags, memories, and related local files between projects/orgs/accounts.

A couple of details I tried to make robust:

--profile remains a config overlay; --auth-profile is the state/auth boundary.
MCP OAuth tokens are profile-scoped, while legacy default-profile keyring credentials still work.
Windows sandbox exec paths receive the resolved profiled Codex home explicitly instead of falling back to the default home.

I could not open a PR against openai/codex from this account because GitHub rejected PR creation, so I am sharing the pushed branch/compare link here for maintainers.

Validation run:

cargo fmt --all
git diff --check
cargo test -p codex-utils-home-dir
cargo test -p codex-rmcp-client oauth::tests
cargo test -p codex-cli --bin codex auth_profile
cargo test -p codex-core build_exec_request_preserves_windows_workspace_roots
broad affected-crate cargo check across home-dir, cli, core, rmcp, mcp, app-server, daemon, chatgpt, cloud-tasks, tui, and exec crates

ChogeShe · 4 days ago

The unified ChatGPT desktop app makes this request more urgent and adds a device-level privacy dimension that is not fully covered by CODEX_HOME or configuration isolation.

Many users pay for Codex through a personal ChatGPT account but need to use Codex on a work or shared computer. Signing into the unified desktop app for Codex can also make personal Chat history and Projects accessible on that device. The employer is not automatically receiving those conversations, but anyone with access to the active OS session or app may be able to view account-wide personal content.

Users need a way to authorize a device for Codex without exposing the rest of their personal ChatGPT account there. Possible solutions include:

a Codex-only device mode that hides Chat, Work, and personal Projects;
per-device access controls for Chat history and Projects;
separate ChatGPT and Codex account profiles within the desktop app;
re-authentication before opening personal Chat history on a work device;
a clear warning during sign-in that account-wide Chat content may become accessible on that device.

This is distinct from billing or simple account switching. The subscription can remain unified; the missing capability is a device-scoped privacy boundary and data-minimization control. For users who need Codex on corporate or shared hardware, this is a privacy and adoption blocker.