Activity

1. github-actions

   added

   enhancementNew feature or requestNew feature or request

   authIssues related to authentication and accountsIssues related to authentication and accounts

   on Jun 30, 2026
2. TarjinderSingh commented on Jul 2, 2026

   

   TarjinderSingh

   on Jul 2, 2026 – with ChatGPT Codex Connector

   More actions

   This is important for anyone using Codex across academic, private, and organizational work.

   These contexts often have different policies, not just different subscriptions. A university/lab workspace, a private consulting account, and a personal account may differ in data handling rules, admin controls, approved connectors, billing, and acceptable tool/plugin use.

   The current logout/login workflow makes it too easy to lose track of which account or workspace is active. That is more than an inconvenience: it can put work under the wrong policy boundary, use the wrong connector permissions, or mix usage and project context across settings that should stay separate.

   Codex should show the active account/workspace clearly and support fast switching with separate cached sessions. This also overlaps with #14330, because for project-based work the account/workspace often needs to align with repo-specific config, tools, and policy.
3. andreagrandi commented on Jul 16, 2026

   

   andreagrandi

   on Jul 16, 2026 – with ChatGPT Codex Connector

   More actions

   A concrete CLI/TUI use case for the “show the current signed-in account and workspace clearly” part of this request:

   I run personal and work ChatGPT accounts concurrently in separate terminals, isolated with different CODEX_HOME directories. The two Codex TUIs are visually indistinguishable, making it easy to run work under the wrong account/workspace.

   Current limitations in Codex CLI 0.144.5:

   • codex login status reports only Logged in using ChatGPT, not which account or workspace is active.
   • [tui].status_line has no account, email, workspace, profile, CODEX_HOME, or config-label item.
   • The status line accepts only fixed built-in item IDs; it cannot display a literal per-config label such as WORK or PERSONAL.
   • Terminal-title fields have the same fixed-item limitation.

   Please support at least one of these:

   1. Built-in account and/or workspace status-line items derived from the authenticated session of that specific TUI process.
   2. A privacy-safe static label stored in each config, for example:

   [tui]
   status_line_label = "WORK"
   status_line = ["status-line-label", "model-with-reasoning", "current-dir"]

   A user-defined label is a useful fallback when exposing an email address is undesirable or when several accounts have similar workspace names.

   Acceptance criteria:

   • Separate CODEX_HOME configurations can display distinct persistent labels.
   • The identity/label remains visible in the TUI footer while multiple sessions run in parallel.
   • Any account-derived value reflects the current TUI session, not the most recently authenticated global session.
   • Email/PII display is opt-in or appropriately redacted.

   This matters beyond convenience: accounts may have different billing, rate limits, data-handling rules, managed policies, and connector permissions.

   Related: #17827 (custom/command-backed status line), #16621 (profile status-line item), #4432 (multi-account auth profiles), and #6360 (session-specific account correctness).

   👍React with 👍1Reacted by Mukund Katpatal

   👀React with 👀1Reacted by Mukund Katpatal
4. chonorov commented on Aug 14, 2026

   

   chonorov

   on Aug 14, 2026

   More actions

   Please make this a first-class, consistent account switcher in both Codex Desktop and the Codex mobile experience. I regularly alternate between two legitimate ChatGPT accounts on the same Mac mini and phone. The current sign-out plus full OAuth/MFA flow interrupts active work and makes it too easy to act under the wrong account.

   Expected UX:

   • keep multiple accounts signed in;
   • switch in one or two clicks/taps;
   • always show the active account/workspace prominently;
   • preserve each account's projects, tasks, chat history, usage limits, settings, and authentication state;
   • offer the same account list and switching behavior in Desktop and mobile/Remote Control.

   This is account switching, not merging accounts. Please coordinate the desktop scope in #31778 with the mobile scope in #31187 so the experience ships consistently.

   ❤️React with ❤️1Reacted by Coro Juan Manuel
5. aderici commented on Aug 16, 2026

   

   aderici

   on Aug 16, 2026

   Last edited by aderici

   More actions

   Is there a strategy to "not bring this"? If so tell us so i will find another provider or a solution. This is frustrating. I need to be able to use codex mobile with 2 accounts on mobile. Because i have an account under company email and another one i use personally on personal email. But i have a single phone
6. huangdijia commented on Aug 26, 2026

   

   huangdijia

   on Aug 26, 2026

   More actions

   I would like to add a more specific workspace-switching use case for Codex Desktop: one ChatGPT account can belong to both a Personal workspace and a Business workspace.

   Today, users need a fast and unambiguous way to move between those workspaces without signing out or completing OAuth again. This is distinct from switching between two different login accounts.

   Suggested acceptance criteria for the desktop app:

   • The active ChatGPT workspace is always visible in the main UI.
   • A user can switch between an available Personal workspace and Business workspace in one or two clicks.
   • After switching, Codex immediately uses the selected workspace's usage limits, admin policies, connectors/plugins, projects, and task history.
   • The app does not display or execute a task under the wrong workspace while switching.
   • Local project folders remain available, while workspace-scoped cloud data and permissions stay isolated.

   This would make mixed personal/work usage both faster and safer, especially when the two workspaces have different data-handling and administrator policies.

   👍React with 👍7Reacted by Flc゛, pyroflux, brokenbones, Coro Juan Manuel, Nils DEYBACH, Sergio Alejandro Ruiz and Ben Brown
7. JMReader commented on Aug 29, 2026

   

   JMReader

   on Aug 29, 2026 – with ChatGPT Codex Connector

   More actions

   I’d like to add another concrete use case for this.

   For me, account switching is not only about avoiding repeated login/logout. I regularly work across two genuinely separate contexts:

   • Work — company ChatGPT account/workspace, with its own policies, permissions, credentials and potentially MCP configuration.
   • Personal — personal ChatGPT account/workspace, with a different identity and environment.

   Ideally Codex would treat these as separate identity/workspace contexts rather than just swapping the currently active OAuth token.

   Conceptually, I’d expect something like:

   Work profile → account + workspace + auth + workspace-specific state

   Personal profile → account + workspace + auth + workspace-specific state

   and an explicit switch action across App / CLI / IDE.

   This also seems related to #4432 and #31778, although I think the important primitive is broader than a CLI --auth-profile: the profile/context should probably exist below the individual surfaces so App, CLI and IDE can share the same semantics.

   I’m interested in digging into the current auth/app-server architecture and documenting a possible design. Before going too far: does this general “identity/workspace context” direction match how the Codex team is thinking about multi-account support?
8. Rj1986 commented on Aug 30, 2026

   

   Rj1986

   on Aug 30, 2026

   More actions

   A closely related real-world use case is a consultant/developer who must use a client-managed ChatGPT Business workspace for that client's repositories while using a separate personal Pro account for independent projects on the same workstation. The client requires its work to remain inside its managed workspace because that workspace is part of its ISO-/ISMS-controlled environment, policies, audit trail and governance scope. A personal account is outside that controlled scope and therefore cannot be used for the client's work.

   The separation is also necessary for correct usage attribution. Client workspace credits should be used only for client work, while independent work should consume the developer's personal Pro allowance. Conversely, client work should not consume the personal allowance. This request is not intended to combine or circumvent usage limits; it is intended to keep compliance scope, billing and usage ownership correct.

   The ideal workflow would allow multiple signed-in auth profiles and bind an account/workspace to each local or remote project. The active identity should always be clearly visible, and Codex should prevent a thread from being resumed under the wrong identity without confirmation.

   Auth tokens, usage attribution, histories/sessions, memories, MCP OAuth credentials and managed workspace policy should be isolated per profile. At the same time, users should be able to share non-secret local defaults such as model settings, rules, skills and general configuration across profiles. Project-specific MCP servers, for example separate Git hosting connections, should remain isolated and automatically follow the selected project/profile.

   This is especially important on Windows with WSL or SSH remote projects, where changing the desktop account can otherwise leave remote authentication or local state associated with the previous identity. First-class per-project account/workspace binding would remove a significant risk of accidentally processing client work under a personal plan, or personal work under a client-managed workspace.
9. ANDREANIADS commented on Sep 1, 2026

   

   ANDREANIADS

   on Sep 1, 2026 – with ChatGPT Codex Connector

   More actions

   [RFC] Safe manual account/workspace switching with local project continuity

   This is a design-only follow-up to #30684. No
   implementation or proof of concept has been started.

   Scope

   The proposal is first-class, manual switching among legitimate personal, professional, and
   ChatGPT Business workspace identities while the current local project remains open. Project path,
   cwd, files, and Git state stay unchanged. Credentials, threads, workspace state, subscription,
   usage, and remote account state remain isolated by account/workspace.

   This explicitly excludes automatic account rotation, entitlement or rate-limit bypass, credential
   copying, and cross-account thread execution. A thread may start a new model turn only when its
   immutable account-profile affinity matches the active account profile; workspace remains part of
   the validated active identity, not persisted thread affinity.

   Main upstream question: existing AccountSessions* types

   At
   openai/codex@c7c824dce4da186e5142af5d9a1587ae553efe46,
   codex-rs/app-server-protocol/src/protocol/v2/account.rs:191-261
   already defines:

   • AccountSessionsAddParams
   • AccountSessionsListParams
   • AccountSessionsLogoutParams
   • AccountSessionsSwitchParams
   • AccountSessionsResponse
   • AccountSession
   • AccountSessionWorkspace
   • AccountSessionWorkspaceKind

   They model an active session, account/workspace selection, and add/list/logout/switch inputs. I
   cannot find a registered account/sessions/* method or public app-server handler in that commit.

   Could a maintainer clarify whether these types are an intended future public surface, a
   private/internal contract, or abandoned work? I do not want to infer intent or propose a competing
   API.

   Why core/app-server coordination is required

   The same commit shows a single consistent active auth snapshot in
   AuthManager,
   a singular load/save/delete storage contract in
   AuthStorageBackend,
   global
   account-auth serialization
   but
   turn/start serialization by thread,
   and no account owner in the persisted
   threads schema.

   A safe switch therefore needs an app-server identity barrier: if active responses, turns, tool
   calls, approvals, user-input waits, or auth mutations are blockers, the request fails fast without
   starting the transition. Cancellation or waiting happens separately, followed by a new switch
   request. Once admitted, no new identity-bound work starts. Identity-bearing services and caches are
   generation-fenced and must reconnect before success is published. Failure must end in a complete
   rollback or a fail-closed recovery state. The local project remains open throughout.

   Five blockers before any PoC

   1. Confirm the intended status, stability, and RPC naming of AccountSessions*.
   2. Decide whether adding a profile extends AccountSessionsAddParams or targets the existing
      account/login/start flow at an isolated session slot.
   3. Identify every mandatory identity-bearing service/cache/connection that must reconnect before a
      switch can report success.
   4. Define how external token hosts, workload identity, API keys, and Bedrock auth map to account
      sessions without weakening isolation.
   5. Define migration and safe downgrade behavior after multi-profile credential storage is enabled.

   I have prepared a source-pinned RFC package with formal safety invariants, an evidence map, state
   machine, threat model, and conceptual API notes. I can share that package in this issue if this is
   the right design direction. Until these blockers receive maintainer guidance, no implementation
   will be started.
10. canu0205 commented on Sep 17, 2026

    

    canu0205

    on Sep 17, 2026

    More actions

    I built a small macOS workaround for the manual-switching part of this: coduck.

    coduck login work, coduck login personal, then coduck run work starts the official Codex CLI with that profile's isolated credential. It keeps normal local Codex state such as settings, instructions, skills, memories, and sessions shared, and it does not change the ChatGPT desktop app login.

    It supports several terminal sessions at once and deliberately does not do automatic rotation or quota-aware routing. I built it after codex /logout also signed me out of the desktop app.

    It is an early macOS-only workaround, but it may be useful until first-class account/workspace profiles ship.
11. nepfaff commented on Sep 18, 2026

    

    nepfaff

    on Sep 18, 2026

    More actions

    Strong support for this. I need to use separate work and personal ChatGPT accounts on the same machine. Please preserve separate authentication, workspace policies, billing/usage, sessions, and history, while showing the active account clearly. This is account isolation—not account merging or quota bypass.
12. w1kke commented on Sep 19, 2026

    

    w1kke

    on Sep 19, 2026

    More actions

    Desktop concept: select the subscription per task beside the model picker

    I work across multiple projects for different organisations, with separate paid subscriptions. I would like to choose which account/workspace's subscription a task uses directly in the desktop composer, alongside the model picker, while keeping each organisation's work separate.

    Adding this concrete UI proposal to the existing request; it also relates to #31778.

    What variant of Codex are you using?

    Codex in the macOS desktop app, version 26.915.31029 (build 9771).

    What feature would you like to see?

    • A visible account/workspace selector in the composer. Show the selected organisation and plan beside the model picker, with an “Add account” action.
    • Per-task selection and project defaults. Choose an identity when starting a task, and optionally save it as the default for new tasks in that project. Changing a project default should leave existing tasks bound to their original identity.
    • Concurrent work for different organisations. A task for Acme uses Acme's subscription while a task for Northstar uses Northstar's subscription. Moving between tasks should preserve those choices.
    • Independent model selection. Keep the model and reasoning controls beside the subscription selector, showing the models available to the selected account/workspace.
    • Consistent identity throughout the task. Resuming a task, background work, and subagents should use its selected identity. Workspace policies, conversation history, memories, and connector credentials should remain correctly scoped. Any change of organisation for an existing task should be explicit, with clear handling of its existing context.

    This would make it easier to attribute usage to the organisation funding the project and avoid repeatedly signing out and back in while working across projects.

    Concept screenshot

    AI-generated UI concept based on the desktop interface, using fictional organisation names. It illustrates the proposed interaction; it is not a screenshot of an implemented feature.

    

    👍React with 👍4Reacted by Bob Langley, f.partonia, Ihab Adham and Roger Göele
13. SergeyYenin commented on Oct 5, 2026

    

    SergeyYenin

    on Oct 5, 2026

    More actions

    I’d like to add my support for this request, specifically switching between Personal and Business workspaces under the same OpenAI account.
    I’m using the macOS app version 26.930.51102. The website lets me switch workspaces directly, but the desktop app has no workspace selector. I can access either workspace by signing out and selecting it during login, but repeating that interrupts my workflow.
    An in-app workspace switcher would be very helpful, with the active workspace clearly displayed so users can confirm which workspace’s usage limits and data policies apply.
    Is this planned, or is there a supported workaround that avoids signing out?