Same email + different workspace login says 'Added account' but overwrites existing saved entry

[adithya04dev]

Summary

When I add another account through codex-multi-auth login, the CLI reports Added account, but if the login is for a different workspace on the same email, the saved account count does not increase.

Instead, the existing saved entry for that email/account family appears to be refreshed or overwritten.

Actual behavior

I can reproduce this with multiple workspaces under the same email:

1. Run codex-multi-auth login
2. Choose Open Browser (Easy) or Manual / Incognito
3. Log into a different workspace using the same underlying email
4. The CLI prints:

Added account. Total: 3
Next steps:
  codex-multi-auth status
  codex-multi-auth check
  codex-multi-auth list

5. After exiting the flow and running codex-multi-auth status, the total is still 3
6. The newly added workspace did not become a separate saved slot; an existing entry appears to have been updated instead

Expected behavior

One of these should happen consistently:

1. If workspace-scoped accounts are intended to be distinct, adding a different workspace on the same email should create a separate saved entry
2. If same-email workspaces are intentionally merged, the login flow should not say Added account when it is actually updating/rebinding an existing saved entry

Right now the UX strongly suggests a new saved account was created, but local storage remains flat.

Local observations

On my machine, repeated browser logins for a different workspace on the same email updated existing saved identities instead of appending a new one.

The stored pool remained at 3 accounts even after successfully completing additional browser logins.

This seems related to deduplication/matching on save rather than a failed OAuth callback.

Why this is confusing

For users with:

• one email
• multiple ChatGPT/OpenAI workspaces

it looks like the tool supports adding another account/workspace, but the saved account count and final stored state do not reflect that mental model.

Suggested fix

At minimum, the login flow should distinguish between:

• Added account
• Updated existing account
• Rebound workspace for existing account

If per-workspace saved entries are a supported goal, then same-email workspaces should be representable as distinct stored entries.

Environment

• codex-multi-auth: 2.2.2
• Official Codex CLI in use through the multi-auth wrapper
• Reproduced on macOS

Additional context

I also observed that status and the dashboard can present slightly different-looking account ordering/state, which makes this even harder to understand during testing. The core bug here, though, is that the browser flow reports Added account while the stored account total does not increase for same-email different-workspace logins.

[coderabbitai]

⚠️ Possible Duplicate Issue(s)

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

🔗 Related PRs

#90 - fix: preserve business accounts that share a workspace accountId [merged]
#122 - fix(quota): keep multi-workspace fallbacks distinct [merged]
#132 - add manual login mode for headless auth flows [merged]
#136 - feat: auto-rotate on disabled/expired workspace errors [merged]
#493 - feat: support multiple workspaces for the same email (#491) [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!

[adithya04dev]

More real-world findings from testing on macOS:

1. The small UX fix is valid:

• after patching locally, a same-email/same-workspace re-login now says Updated existing account. Total: 3 instead of Added account. Total: 3

2. The deeper same-email multi-workspace path still does not work reliably in practice.

What I tested:

• normal browser flow
• manual/incognito flow
• explicit login --org <org_id> flow
• explicit login --manual --org <org_id> flow

What still happens:

• no new distinct workspace becomes usable/saved
• stored account rows still have workspaces: null
• workspace <account> is therefore unusable for the affected account

Important evidence:

• ~/.codex/auth.json for the latest login contained two organizations in the token for the same email, e.g.:
  • org-izb8024fENXhpMsfDt5A7gz3 (Adithya workspace, default)
  • org-r15LU9acpBzLqar9JQgqYqDH (Personal, non-default)
• but ~/.codex/multi-auth/openai-codex-accounts.json still persisted the saved row without a workspaces array

That seems to contradict the intended #491 behavior:

• if one login returns both orgs, the account should persist tracked workspaces
• then codex-multi-auth workspace <account> should handle switching

There is also a separate manual-mode UX bug:

• codex-multi-auth login --manual can print Cancelled. after pasting a localhost callback URL
• in code, the manual callback parser currently returns null for parse/state mismatches, and the caller reports that as Cancelled. instead of surfacing the real validation error

So I think there are actually 2 issues:

1. same-email multi-workspace persistence/binding is still broken in some real accounts even when the token exposes multiple organizations
2. manual callback entry misreports validation/state problems as Cancelled.

If helpful, I can sanitize and attach the relevant auth.json / openai-codex-accounts.json snippets more formally.

[adithya04dev]

One product/UX note from testing this in the real CLI:

Even if the intended post-#491 model is "one saved account row with multiple workspaces underneath it", that model is much harder to reason about in practice than a flat "one workspace = one row" model.

Why it feels confusing as a user:

• a new workspace does not show up like a new account entry
• routing is account-level, but workspace choice is nested under the account
• the user has to understand workspace <account> <workspace> in addition to switch <account>
• when workspace persistence fails, the whole feature becomes hard to distinguish from "login just picked the wrong account"

From a user mental-model perspective, separate rows per workspace would be much easier to understand and debug, especially when different workspaces effectively represent different quota pools / identities for routing purposes.

Not saying the current nested-workspace model must be abandoned, but I wanted to call out that this design choice itself is contributing to the confusion here, independently of the persistence bug.