OpenAI OAuth creates duplicate accounts and disables valid logins

[tdecaluwe]

Bug Description
OpenAI OAuth login succeeds, but oc-codex-multi-auth creates two entries for the same identity (Personal workspace + Token account) and then marks the account disabled/ineligible because it enforces connector scopes that OpenAI did not grant.

Steps to Reproduce

1. Install/configure oc-codex-multi-auth in opencode.
2. Run opencode auth login.
3. Choose OpenAI → Codex OAuth (Device Code) and complete login successfully.
4. Run codex-list, codex-status, or codex-dashboard.

Expected Behavior

• One successful OpenAI OAuth login should create one usable account.
• The account should be eligible for normal model/auth usage after login.
• Missing connector-specific scopes should not disable baseline OpenAI OAuth usage.

Actual Behavior

• Login succeeds, but two entries are created for the same identity: a workspace/org account and a token account
• The returned OAuth scope only contains openid, profile, email and offline_access
• The plugin then marks the account as disabled/blocked/ineligible because it expects api.connectors scopes

Environment

• opencode version: 1.15.5
• Plugin version: oc-codex-multi-auth@6.1.9
• Operating System: Linux
• Node.js version: v24.15.0

Compliance Checklist
Please confirm:

• I'm using this plugin for personal development only
• I have an active ChatGPT Plus/Pro subscription
• This issue is not related to attempting commercial use or TOS violations
• I've reviewed the FAQ and Troubleshooting sections

Additional Context
Relevant logic appears to be in lib/accounts/state.ts:

enabled: account.enabled !== false && (!shouldEnforceScope || missingOAuthScopes.length === 0)

This means a normal OpenAI OAuth login can succeed but still be disabled because OpenAI did not grant the connector scopes. It also appears the fallback/token account creation path can produce a duplicate account entry for the same underlying identity.

[coderabbitai]

Coding Plan

Summary

• remove connector scopes from REQUIRED_OAUTH_SCOPES since openai does not grant them and baseline functionality works without them
• filter redundant token-source variants in resolveAccountSelection before persistence when org-source variants exist for the same accountId
• rely on existing merge logic in persistAccountPool to clean up already-duplicated accounts on next login
• no schema migrations required - changes are backward compatible with existing stored accounts

Design Choices

Design Choice 1: should connector scopes affect account eligibility at all?

Options Considered:

1. remove connector scopes from required list entirely - simplest, matches observed openai behavior
2. create tiered scopes (baseline vs connector) with separate eligibility flags
3. make scope enforcement configurable via feature flag

Chosen Option: 1

Rationale: option 1: remove connector scopes from REQUIRED_OAUTH_SCOPES entirely since openai does not grant them and the plugin functions without them.

Design Choice 2: when should token-source candidates be filtered?

Options Considered:

1. filter in getAccountIdCandidates before returning candidates
2. filter in resolveAccountSelection when building variantsForPersistence
3. rely on deduplication in persistAccountPool to collapse them

Chosen Option: 2

Rationale: option 2: filter in resolveAccountSelection to keep candidate discovery pure and make the filtering logic explicit and testable.

💡 User Tips

Regenerate the plan with different choices with @coderabbitai <feedback>.

Implementation Steps

Phase 1: Fix Scope Enforcement

this phase removes connector scopes from the required list so baseline oauth login produces usable accounts.

Task 1: Remove connector scopes from required scopes

update the scope constants to only require baseline oidc scopes that openai actually grants.

• update lib/auth/scopes.ts:1-10: remove api.connectors.read and api.connectors.invoke from REQUIRED_OAUTH_SCOPES array
• the SCOPE constant (joined string) will automatically reflect the change
• getMissingRequiredOAuthScopes and hasRequiredOAuthScopes need no changes - they operate on the array

note: no changes needed in lib/accounts/state.ts - the enabled logic at lines 141-163 will automatically pass when baseline scopes are present.

Task 2: Verify backward compatibility

ensure existing accounts without stored scopes remain functional.

• confirm shouldEnforceScope logic at lib/accounts/state.ts:141-143 still bypasses validation for accounts with oauthScope === undefined
• existing accounts that were disabled due to missing connector scopes should become enabled after reload
• no migration needed - accounts are re-evaluated on every load

flag: no existing unit tests found for scope enforcement in lib/auth/scopes.ts. add regression tests covering baseline-only scope grants.

🤖 Prompt for AI agents

this phase fixes scope enforcement by removing connector scopes from the
required list so that baseline openai oauth logins produce enabled accounts.

- in `lib/auth/scopes.ts:1-10`, remove `api.connectors.read` and
`api.connectors.invoke` from the `REQUIRED_OAUTH_SCOPES` array. the `SCOPE`
constant (joined string) derives from this array and will update automatically.
do not change `getMissingRequiredOAuthScopes` or `hasRequiredOAuthScopes` — they
operate on the array directly
- no changes required in `lib/accounts/state.ts:141-163` — once the array is
trimmed, the enabled check passes automatically for baseline oauth grants
- confirm that the `shouldEnforceScope` guard at `lib/accounts/state.ts:141-143`
still short-circuits for accounts where `oauthScope === undefined`, preserving
backward compat for existing stored accounts
- flag: add regression tests for scope enforcement in `lib/auth/scopes.ts`
covering: (1) baseline-only scope grant passes `hasRequiredOAuthScopes`, (2)
missing baseline scopes still fail, (3) accounts with `oauthScope === undefined`
are not gated

Phase 2: Fix Duplicate Account Creation

this phase filters out redundant token-source variants when org-source variants exist for the same identity.

Task 1: Add variant filtering logic

add a function to identify and remove redundant token-source candidates.

• create helper function in lib/auth/token-utils.ts (after uniqueCandidates around line 345)
• function should take the candidates array and return filtered array
• filter rule: remove candidates where source === "token" AND another candidate exists with source === "org" and the same accountId
• preserve token-source candidates when no org-source candidate shares their accountId (standalone personal accounts)

Task 2: Apply filtering in resolveAccountSelection

integrate the filter into the account selection flow.

• update lib/auth/login-runner.ts in resolveAccountSelection (around line 217-233)
• apply filter to candidates array before building variantsForPersistence
• ensure the primary selection happens BEFORE filtering so we pick the best candidate first
• filter should only affect what gets persisted, not which candidate becomes primary

concurrency note: persistAccountPool uses withAccountStorageTransaction which holds a mutex (lib/storage/state.ts). filtering happens before the transaction, no concurrency risk introduced.

Task 3: Handle existing duplicate accounts

address accounts that were already duplicated by previous logins.

• on next login, the identity matching in persistAccountPool (lib/auth/login-runner.ts:603-718) should merge the redundant token-source entry with the org-source entry
• the byRefreshTokenGlobal lookup combined with canCollapseWithCandidateAccountId handles this
• no explicit migration needed - duplicates collapse on next auth cycle

flag: add regression test for the filtering logic. test case: jwt with both chatgpt_account_id claim and organizations array containing same accountId should produce single persisted account.

flag: windows users may have existing duplicate accounts in %LOCALAPPDATA%. confirm dedup path works on next login - no special handling needed since storage layer is cross-platform.

🤖 Prompt for AI agents

this phase eliminates duplicate account entries by filtering redundant
token-source candidates before persistence when an org-source candidate already
covers the same accountId.

**task 1 — helper function in `lib/auth/token-utils.ts` (after
`uniqueCandidates`, ~line 345)**
- create a new helper function that takes a candidates array and returns a
filtered array
- filter rule: drop any candidate where `source === "token"` AND another
candidate in the array has `source === "org"` with the same `accountId`
- do NOT drop token-source candidates that have no org-source counterpart —
these represent standalone personal accounts and must be preserved

**task 2 — wire the filter in `lib/auth/login-runner.ts:resolveAccountSelection`
(~line 217-233)**
- apply the new helper to the candidates array before building
`variantsForPersistence`
- primary candidate selection must happen BEFORE the filter runs — pick the best
candidate first, then filter what gets persisted
- the filter must not affect which candidate becomes primary
- concurrency note: `persistAccountPool` uses `withAccountStorageTransaction`
which holds a mutex (`lib/storage/state.ts`). filtering happens before the
transaction opens, so no concurrency risk is introduced

**task 3 — confirm existing duplicate cleanup path**
- verify that `persistAccountPool` (`lib/auth/login-runner.ts:603-718`) merges
redundant token-source entries with org-source entries via the
`byRefreshTokenGlobal` lookup and `canCollapseWithCandidateAccountId` — no
explicit migration code needed
- flag: add regression test covering the case where a jwt contains both a
`chatgpt_account_id` claim and an `organizations` array entry with the same
accountId — the result after `resolveAccountSelection` should be a single
persisted account, not two
- flag: confirm the `byRefreshTokenGlobal` + `canCollapseWithCandidateAccountId`
dedup path works correctly for windows users with existing duplicates in
`%LOCALAPPDATA%` — no special handling needed since the storage layer is
cross-platform

Research

the plugin uses a multi-account storage system where accounts are keyed by organizationId → accountId → refreshToken hierarchy (lib/storage/identity.ts). oauth login extracts all possible identity candidates from jwt claims via getAccountIdCandidates (lib/auth/token-utils.ts:450), then persists all of them as separate variants via persistAccountPool (lib/auth/login-runner.ts:348). scope enforcement happens at load time in AccountState.initializeFromStorage (lib/accounts/state.ts:141-163), gating the enabled field against a flat list of 6 required scopes including connector scopes.

---

🚀 Next Steps

🤖 All AI agent prompts combined

Task: 1

this phase fixes scope enforcement by removing connector scopes from the
required list so that baseline openai oauth logins produce enabled accounts.

- in `lib/auth/scopes.ts:1-10`, remove `api.connectors.read` and
`api.connectors.invoke` from the `REQUIRED_OAUTH_SCOPES` array. the `SCOPE`
constant (joined string) derives from this array and will update automatically.
do not change `getMissingRequiredOAuthScopes` or `hasRequiredOAuthScopes` — they
operate on the array directly
- no changes required in `lib/accounts/state.ts:141-163` — once the array is
trimmed, the enabled check passes automatically for baseline oauth grants
- confirm that the `shouldEnforceScope` guard at `lib/accounts/state.ts:141-143`
still short-circuits for accounts where `oauthScope === undefined`, preserving
backward compat for existing stored accounts
- flag: add regression tests for scope enforcement in `lib/auth/scopes.ts`
covering: (1) baseline-only scope grant passes `hasRequiredOAuthScopes`, (2)
missing baseline scopes still fail, (3) accounts with `oauthScope === undefined`
are not gated
===============================================================================

Task: 2

this phase eliminates duplicate account entries by filtering redundant
token-source candidates before persistence when an org-source candidate already
covers the same accountId.

**task 1 — helper function in `lib/auth/token-utils.ts` (after
`uniqueCandidates`, ~line 345)**
- create a new helper function that takes a candidates array and returns a
filtered array
- filter rule: drop any candidate where `source === "token"` AND another
candidate in the array has `source === "org"` with the same `accountId`
- do NOT drop token-source candidates that have no org-source counterpart —
these represent standalone personal accounts and must be preserved

**task 2 — wire the filter in `lib/auth/login-runner.ts:resolveAccountSelection`
(~line 217-233)**
- apply the new helper to the candidates array before building
`variantsForPersistence`
- primary candidate selection must happen BEFORE the filter runs — pick the best
candidate first, then filter what gets persisted
- the filter must not affect which candidate becomes primary
- concurrency note: `persistAccountPool` uses `withAccountStorageTransaction`
which holds a mutex (`lib/storage/state.ts`). filtering happens before the
transaction opens, so no concurrency risk is introduced

**task 3 — confirm existing duplicate cleanup path**
- verify that `persistAccountPool` (`lib/auth/login-runner.ts:603-718`) merges
redundant token-source entries with org-source entries via the
`byRefreshTokenGlobal` lookup and `canCollapseWithCandidateAccountId` — no
explicit migration code needed
- flag: add regression test covering the case where a jwt contains both a
`chatgpt_account_id` claim and an `organizations` array entry with the same
accountId — the result after `resolveAccountSelection` should be a single
persisted account, not two
- flag: confirm the `byRefreshTokenGlobal` + `canCollapseWithCandidateAccountId`
dedup path works correctly for windows users with existing duplicates in
`%LOCALAPPDATA%` — no special handling needed since the storage layer is
cross-platform

💡 Iterate on the plan with: @coderabbitai <feedback>

Example Feedback
- @coderabbitai You can skip phase 3. Add a simple unit test case for phase 2.
- @coderabbitai For design choice 1 go ahead with option 3 and replan.

---

💬 Have feedback or questions? Drop into our discord!

[tdecaluwe]

@coderabbitai Description was updated

[coderabbitai]

I've updated the plan above based on your feedback. Ready to proceed when you are!

[coderabbitai]

I've updated the plan above based on your feedback. Ready to proceed when you are!

[coderabbitai]

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
gh issue view 156 --repo ndycode/oc-codex-multi-auth --json title,body,comments,labels,assignees,state

Length of output: 31354

---

@tdecaluwe the plan was already generated from your updated description — no action needed on your end to trigger a replan. here's a quick summary of what's covered:

phase 1 — fix scope enforcement (lib/auth/scopes.ts:1-10)

• drop api.connectors.read and api.connectors.invoke from REQUIRED_OAUTH_SCOPES; openai doesn't grant them and the plugin works without them
• no changes needed in lib/accounts/state.ts:141-163 — the enabled check passes automatically once the array is trimmed
• the shouldEnforceScope guard at lib/accounts/state.ts:141-143 continues to short-circuit for accounts with oauthScope === undefined (backward compat preserved)
• ⚠️ missing regression tests flagged: lib/auth/scopes.ts needs tests for (1) baseline-only grant passes, (2) missing baseline scopes still fail, (3) oauthScope === undefined is not gated

phase 2 — fix duplicate account creation (lib/auth/token-utils.ts, lib/auth/login-runner.ts)

• add a helper after uniqueCandidates (~lib/auth/token-utils.ts:345) to drop candidates where source === "token" when an source === "org" candidate shares the same accountId
• wire it in lib/auth/login-runner.ts:resolveAccountSelection (~line 217-233) before building variantsForPersistence, after primary selection
• existing duplicates collapse on next login via byRefreshTokenGlobal + canCollapseWithCandidateAccountId in lib/auth/login-runner.ts:603-718 — no migration needed
• ⚠️ concurrency note: filtering happens before withAccountStorageTransaction mutex in lib/storage/state.ts — no risk introduced
• ⚠️ windows: existing duplicates in %LOCALAPPDATA% will self-heal on next login — storage layer is cross-platform
• ⚠️ missing regression test flagged: jwt with both chatgpt_account_id claim and matching organizations entry should persist as a single account

the full ai-agent prompts are in the plan above. you can iterate with @coderabbitai <feedback> if you want any design choices revisited.