Feature request: support multiple named accounts per app/connector

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

• #19489
• #19669

Powered by Codex Action

I work across multiple companies, each with separate Google logins. Ideally i could instantiate separate connectors for each account, then reference them explicitly, e.g. "Check Business A email for..."
I want to do this from within one codex / chatgpt account.

I'm running into this limitation as well. I regularly need to access multiple Google Workspace accounts (work, freelance, school, personal). Has anyone found a practical interim workaround or pattern for managing this more efficiently (multiple MCPs, custom plugins, or something else entirely)?

Adding a project-scoped use case that is slightly narrower than the broader multi-account request here.

I often work across multiple Codex Desktop projects/repos that map to different real-world identities. For example:

• a company/work repo should use a work Gmail / Calendar / Drive account;
• a personal product repo should use a personal Gmail / Calendar / Drive account;
• client repos may need client-specific Slack/Drive/GitHub connector identities.

Today, the connector identity appears to be global for the provider/session. In practice this makes write-capable connectors risky: when Codex drafts or sends email, searches Drive, reads calendar events, or posts to Slack, I need to be sure the action is happening from the account that belongs to the current project context.

A useful extension of this feature would be project/workspace-level connector defaults, for example:

• ~/.codex/config.toml or Desktop project settings can bind /path/to/project-a to Gmail - Work and /path/to/project-b to Gmail - Personal;
• the active project UI clearly shows which connector account will be used before any read/write action;
• if a project has no matching connector account configured, Codex should ask instead of silently falling back to a global account;
• side-effecting actions should confirm the selected account/workspace, especially for Gmail, Calendar, Drive, Slack, and GitHub.

This would reduce accidental cross-contamination between personal, company, and client data while preserving the convenience of automatic connector use.

I really need this feature as well. For me, it's Notion, but the principle is the same. I have a workspace that is integral to the way a particular project in Codex functions in terms of the automations I've set up. I have this architecture set up for multiple projects, each with their own Notion workspace.

I've just discovered that I can only have the Notion account that I've connected in Codex connected to one of those workspaces, which completely prevents me from doing what I'm trying to do. I'm really hoping the ability to create multiple instances of each connected provider comes soon.

+1. Would love to run the same automations for multiple Slack + multiple Gmail accounts. It's a bummer that I've discovered some really good workflows / automations but can only do one pair of accounts at a time

+1 to this.

I have two personal email/google accounts, and a business google workspace.
I want to make codex desktop my daily driver for everything.

It would be amazing if I can connect them all to codex with controls (e.g. slice it by project etc.)

I also very much need this feature. Who doesn't have more than one gmail account?

Yes I need this too

worked on this and a PR can be opened here: https://github.com/openai/codex/compare/main...iamhectorlopez:codex/multi-account-app-aliases?expand=1

tldr:
Codex Apps should support user-defined account aliases like Personal, Work, and University. The model can route by alias or ask when ambiguous, while the app UI can manage per-alias connections. This avoids picker spam and creates a clean path to true multi-account OAuth.

The missing production pieces are:

1. OAuth storage keyed per app account

Example key: (app_id, account_alias) or (connector_id, account_alias).

1. Connect flow accepts an alias

The UI/backend needs per-alias account actions, where aliases are fully user-defined: “Connect Personal”, “Reconnect Client A”, “Disconnect University”, etc., instead of one global “Connect Gmail”.

1. Tool calls carry the selected account

When Codex decides “use Work”, that alias must reach the connector/tool execution layer.

1. Per-alias connection state in UI

The plugin page should show:
Personal -> Connected
Work -> Connect
University -> Reconnect

1. Safety/provenance

Tool results should probably expose or log “using Work Gmail” so the model and user do not accidentally mix accounts.

1. End-to-end tests with fake multiple sessions

A mock app should prove two aliases can return different data.

This request maps directly to a real failure we hit today. I use a self-serve ChatGPT Business workspace for company knowledge work and Agents, but I also need a personal Pro account for higher-capacity Codex work. The same GitHub identity was connected to both workspaces. Codex code review silently billed/routed PR reviews to the exhausted Business workspace even though the Pro account had substantial usage remaining. The Pro usage dashboard and GitHub error therefore contradicted each other.

The only working recovery was to open the Business account in an Incognito window, disable auto-review, disconnect GitHub there, reconnect GitHub under Pro, and test again. There was no visible account/workspace selector explaining which entitlement would be used.

The broader business need is mixed seat tiers within one governed Business workspace: standard seats for most employees and Pro-capacity seats for a smaller group of power users. Separate personal Pro accounts fragment Agents, company knowledge, permissions, analytics, billing, and connector identity. At minimum, GitHub and other connectors should show and require an explicit account/workspace selection, including which usage pool will be charged.

+1, I would get a ton of value from this feature.

+1 - I use separate personal and work Gmail accounts, and switching the active connection is easy to get wrong. Named connections with a clear active-account indicator would be hugely useful.

+1, I'm trying to build a work around using MCP but would love this in the app.

Agreed. Come on guys! I have three different Google accounts I want to be
able to access simultaneously.

On Mon, 13 Jul 2026 at 17:38, Ahmaad @.***> wrote:

ahrsn left a comment (openai/codex#20500) <https://github.com/openai/codex/issues/20500#issuecomment-4959737388> +1, I'm trying to build a work around using MCP but would love this in the app. — Reply to this email directly, view it on GitHub <https://github.com/openai/codex/issues/20500?email_source=notifications&email_token=AAKSCNXMJ3KXLYIUAIKOC4T5ET7BHA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIOJVHE3TGNZTHA4KM4TFMFZW63VHMNXW23LFNZ2KKZLWMVXHJLDGN5XXIZLSL5RWY2LDNM#issuecomment-4959737388>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAKSCNTVH5MZWIOWFQA3C6T5ET7BHAVCNFSNUABFKJSXA33TNF2G64TZHM4TMNJUGE2TMNBZHNEXG43VMU5TIMZWGEZDOMBUGA3KC5QC> . You are receiving this because you commented.Message ID: @.***>

+1, I have to use alias path declared in zsh as workaround, but can only use with codex cli. Love the app so wishing this feature official support in Codex / ChatGPT app!

pls

I also have separate personal and work gmail account and google drive.

+1 from me.

This would make a huge difference to my workflow. I have:

• 2 Slack accounts
• 3 Gmail accounts
• Multiple Linear accounts

I’d love to be able to connect all of them and either choose which account to use for a given prompt or search across all connected accounts when appropriate.

It would also be helpful to give each connected account a friendly name (e.g. “Personal” and “Work”) so it’s obvious which account ChatGPT is using.

It has been too long, ChatGPT is not usable if it can access only 1 Gmail account, OpenAI please update

Bump, I work for multiple companies and some have their own workspaces, having to sign off then sign in each time is a huge hassle.

Bump, I work for multiple companies and some have their own workspaces, having to sign off then sign in each time is a huge hassle.

Superhuman just solved this on their end:

<img width="1890" height="1654" alt="Image" src="https://github.com/user-attachments/assets/4360bae4-8e52-4ef2-90b5-9e3a5ddc0d9a" />

But we still want to be able to do this for every connector 😉

+1, I'd love to connect each family member's personal email / drive to one GPT account

A related Gmail-specific case is worth including in the acceptance criteria: multiple verified Send mail as identities within a single connected Gmail account.

This is distinct from connecting multiple OAuth accounts. A user can have one primary Gmail mailbox with several verified sender identities, including Google Workspace or custom-domain addresses. Gmail’s web UI and Gmail API support these SendAs aliases, but the current Codex Gmail connector tools do not expose a from / sendAsEmail parameter for send, draft, reply, or forward operations. As a result, Codex cannot explicitly select or guarantee the correct sender identity even when Gmail is already configured correctly.

A safe implementation could:

• list only verified users.settings.sendAs identities;
• expose a stable sender identity to send_email, create_draft, reply, and forward tools;
• default replies to the identity that originally received the message;
• ask or fail closed when the sender is ambiguous;
• show the resolved From address in every write confirmation.

We reproduced this with one personal Gmail account and two verified Google Workspace Send-as identities. Both identities work correctly in Gmail web, but the connector cannot select either because its write tool schemas have no sender field.

This would complement multi-account support and prevent mail from being sent under the wrong personal or company identity.

Confirmed this in a real ChatGPT Gmail workflow today.

I use two Gmail identities and explicitly tested whether the integration can target both. I created two drafts, one addressed to each mailbox, then read both drafts back through the Gmail connector. Both drafts were still created from the same currently authenticated Gmail identity. The Gmail draft action exposes no account, connection_id, or from selector.

This is already causing practical problems for job-application workflows: the message body/signature can contain the intended address while the actual sender identity is a different connected Gmail account. That is subtle and easy to miss.

The most useful fix for me would be exactly what this issue proposes:

• multiple named Gmail connections visible at the same time;
• an explicit account/connection parameter on search/read/draft/send actions;
• source-account metadata on results;
• replies inheriting the mailbox/thread identity automatically;
• fail closed when sender/account selection is ambiguous rather than silently using the current OAuth identity.

Personal + work is only the simplest example. Freelancers, consultants, founders, and users migrating from an old address to a new one routinely need two or more mailboxes in the same ChatGPT workflow.

yes just set up google workspace for a team and now i have to decide if want to continue connecting to my google workspace or the workspace of the team, ideally i would like to have both in parallel. would love if this would become a thing!! <3

+1. Working on projects with different Google Workspace accounts for each one, using each of those accounts for Google APIs, Supabase, Firebase and other stuff, Codex becomes very risky when we sometimes inadvertently mix up the accounts used. A "profile selector" that remembers which accounts were logged in to that profile would be perfect.

wen?

"Labeled, simultaneous connections" is the right framing — that's the model I went with.

One thought on the guardrails: a gateway can't decide what an ambiguous request means, it doesn't have the conversation. What it can do is expose real identity per account — the email, the workspace name — not just a label. Then the client can resolve it or ask.

Disclosure: I'm the founder of ProxyLoom — https://proxyloom.dev/en/ Open beta, free for now.