[feature] Support registering multiple workspaces for the same email (personal + business/team under one Google account)

[MarsGao]

Background

Issues #100 and #121 touched this topic. #121 was closed with fix in b918aac, which addressed quota-cache display for same-email multi-workspace entries that were already stored. However, the registration path (i.e., running codex-multi-auth login to add a second workspace for an email that already has one) remains unsupported.

Use Case

A user has a single Google/OpenAI account (user@gmail.com) that belongs to two separate ChatGPT workspaces:

• Personal Plus – individual subscription, org_id = org-AAAA
• Business / Team workspace – organization subscription, org_id = org-BBBB

Both workspaces are distinct quota pools. The user wants to track and rotate between them independently, just like two separate email accounts.

Current Behavior

1. codex-multi-auth login with user@gmail.com → OAuth completes for one workspace (e.g., Business) → stored as Account N.
2. Running codex-multi-auth login again for the same email (Personal Plus workspace) either:
   • Overwrites Account N (loses the Business workspace entry), or
   • Blocks the addition because the duplicate-email doctor check treats email as the unique key.
3. The accounts.json schema has no workspaceName/workspaceId field populated, so there is no way to distinguish the two entries even if both were stored.

Expected Behavior

Option A – Workspace selection during login: when codex-multi-auth login detects the OAuth response belongs to an email already registered but with a different accountId (org_id), prompt the user to confirm adding it as a new entry rather than overwriting.

Option B – Explicit workspace flag: codex-multi-auth login --new-workspace or codex-multi-auth login --org <org_id> to force-create a second entry for the same email.

Either way, the stored entry should include a workspaceName or workspaceLabel field so codex-multi-auth list can distinguish:

1. user@gmail.com  [Personal Plus]   org-AAAA
2. user@gmail.com  [GkTech Business] org-BBBB

Environment

• codex-multi-auth version: 2.1.12
• @openai/codex version: 0.135.0
• OS: Windows 11 Enterprise
• Node.js: (via C:\nodejs)

Diagnostics

Current accounts.json structure (sanitized):

{
  "accounts": [
    { "email": "user@gmail.com", "accountId": "org-AAAA", "workspaceName": "" },
    { "email": "user@gmail.com", "accountId": "org-BBBB", "workspaceName": "" }
  ]
}

The workspaceName field is always empty even after login, making it impossible to label or distinguish same-email entries.

Related Issues

• [feature] account with mutible workspace #100 [feature] account with multiple workspace (closed, no implementation)
• [bug] Seem like the feature of account got muti team did not working right ? #121 [bug] account with multi-team not working right (closed, fix only addressed quota cache display, not registration)

Compliance

• I am using this project for personal development workflows (multiple ChatGPT subscriptions owned by the same person).
• This request does not ask for credential sharing, policy bypass, or resale use.
• No secrets or tokens are included in this report.

[coderabbitai]

🔗 Related PRs

#122 - fix(quota): keep multi-workspace fallbacks distinct [merged]
#136 - feat: auto-rotate on disabled/expired workspace errors [merged]
#463 - Fix runtime skip for deactivated accounts [merged]

---

📝 Issue Planner

_{Check the box below or use the @coderabbitai plan command to generate an implementation plan and prompts that you can use with your favorite coding assistant.}

• Create Plan

---

🧪 Issue enrichment is currently in open beta.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord!

[ndycode]

Shipped in 2.1.13-beta.1 on the npm beta tag (PR #493).

npm i -g codex-multi-auth@beta

What changed:

• Account workspaces now persist across reloads. The root cause was the strict storage schema stripping the workspaces / currentWorkspaceIndex fields on every load, so login captured them but the next read wiped them. That is why the workspace label always came back empty.
• list / status surface the active workspace name and list every workspace under an account, so two same-email entries are distinguishable.
• New codex-multi-auth workspace <account> [workspace] lists or switches the active workspace.
• New codex-multi-auth login --org <org_id> binds a login to a specific workspace/org, so a second workspace can be registered on demand.

Could you help confirm one thing on your real two-workspace account? After codex-multi-auth login, run codex-multi-auth list and check whether both workspaces appear under one account. The open question is whether a single login returns both orgs in the token (then the workspace command alone covers switching) or one org at a time (then login --org <org_id> is the path to add the second). A sanitized list output, or the workspaces arrays from ~/.codex/multi-auth/openai-codex-accounts.json with tokens/emails redacted, would confirm which path you hit.