Security Incident Report: Cross-Account GitHub Authentication Confusion

What version of the Codex App are you using (From “About Codex” dialog)?

Powered by Codex & OWL Version 26.715.72359

What subscription do you have?

MAX 20X

What platform is your computer?

Darwin 25.4.0 arm64 arm

What issue are you seeing?

Security Incident Report: Cross-Account GitHub Authentication Confusion

1. Executive Summary

This report documents a serious authentication-control failure involving two GitHub accounts used during the same AI-assisted working session.
Account A was not merely the user’s intended account. Earlier in the same session, Account A was the actual authenticated identity used to access and push to a private repository. Account B was later introduced for work involving a separate public repository. At some point after that account change, the local GitHub authentication state no longer provided valid access to Account A, while the browser remained signed in as Account B.
When a later push to Account A’s private repository failed, the AI assistant correctly observed that the repository remote still pointed to Account A’s private repository. It also observed that the GitHub CLI authentication state was invalid. However, the assistant then made a critical security error: it initiated the generic GitHub CLI browser-based device login flow and described the operation as if it would authenticate only Account A.
The command used, gh auth login --web, could select the GitHub host but could not bind the new authentication to a specific username. The browser—not the AI assistant or the repository remote—determined which account would authorize the device. Because the browser was signed in as Account B, GitHub displayed an authorization page for Account B.
The user detected the mismatch after GitHub requested an additional email verification code. The user then ordered the process to stop, and the local GitHub CLI polling process was terminated.
The incident did not result in a repository push, remote modification, merge, or confirmed transfer of source code. However, the authentication attempt itself was unsafe. The assistant supplied a device code, represented the process as Account A authentication, and encouraged the user to complete an authorization that was actually associated with Account B.
This behavior reasonably resembled a social-engineering pattern. The absence of malicious intent does not reduce the security severity. Security must be evaluated according to the observable process, the authority requested, the information presented to the user, and the potential consequences.

1. Corrected Factual Model

The correct factual model is:
Account A was the previously authenticated and operational GitHub identity.
Account A had already been used during the same working session for the private repository.
Account B was a separate GitHub identity associated with public-repository work.
The browser remained signed in as Account B.
The local GitHub CLI later reported invalid authentication for both stored accounts.
The repository remote still pointed to Account A’s private repository.
The AI assistant attempted to restore Account A access by invoking a generic GitHub device login.
The device login was not technically restricted to Account A.
GitHub therefore used the browser’s active identity, Account B.
The user—not the model—detected the identity mismatch.
The failure should therefore be described as an authentication-context drift and identity-continuity failure.
It was not simply a case where the user requested Account A and the browser happened to contain Account B. Account A had already been established as the authoritative operational identity. The assistant failed to preserve, verify, or safely restore that identity after another account entered the environment.

1. Incident Timeline

The relevant events occurred in this order:
Account A was successfully used for earlier private-repository operations.
Account B was subsequently used in connection with a separate public repository.
The working session continued with both account identities present in local or browser state.
A local commit containing two project handoff files was created successfully.
A push to Account A’s private repository failed with Repository not found.
Read-only diagnostics confirmed that the Git remote still pointed to Account A’s private repository.
GitHub CLI diagnostics reported that Account B was the active stored account, but its token was invalid.
Account A was also listed, but its token was invalid and it was not active.
An attempt to remove Account B’s local CLI login record failed because GitHub CLI could not update the macOS Keychain state.
The user instructed the assistant to leave the public-repository account alone and authorized only the reauthentication of Account A.
The assistant started gh auth login --hostname github.com --git-protocol https --web --skip-ssh-key.
GitHub CLI generated a device code and opened the GitHub device authorization page.
The assistant instructed the user to verify Account A, despite having no technical mechanism to bind the device flow to Account A.
The browser displayed “Signed in as Account B.”
GitHub requested an email verification code for Account B.
The user recognized the security problem and ordered STOP.
The assistant terminated the local device-flow polling process.
No push was performed.
The decisive failure occurred before the user entered the final authorization. The assistant initiated and represented an account-neutral authorization flow as an account-specific flow.

1. Technical Explanation

GitHub CLI’s browser login uses an OAuth device authorization flow.
The CLI requests a one-time device code and instructs the user to enter that code at GitHub’s device authorization page. The CLI then polls GitHub until the user completes authorization, rejects the request, or the code expires.
The official GitHub CLI manual documents options for the hostname, browser flow, Git protocol, scopes, credential storage, and token input. It does not provide a --user option for gh auth login. See the official gh auth login documentation.
GitHub CLI does provide a --user option for gh auth switch, but that command only switches between accounts whose credentials are already stored. It does not make a new browser login account-specific. See gh auth switch.
This difference is critical:
gh auth switch --user AccountA can select an existing stored account.
gh auth login --web begins a new browser authorization without binding the request to Account A.
The browser session determines which GitHub identity approves the request.
The repository remote does not determine the OAuth identity.
The model’s conversational intention does not determine the OAuth identity.
GitHub’s own OAuth documentation warns that users may change which account they are signed into during authorization and that applications risk mixing user data unless identity is validated after every sign-in. See GitHub’s OAuth authorization documentation.
The AI assistant therefore did not possess a valid technical control capable of fulfilling the promise “only authenticate Account A.”

1. Primary Security Failure

The primary failure was false identity assurance.
The assistant stated that the process would authenticate only Account A, even though the selected command could not enforce that condition. This transformed an unknown security state into an unsupported assurance.
The appropriate statement would have been:
This device code is not bound to a username. It will authorize whichever GitHub account is currently active in the browser. Do not proceed until the browser identity has been independently verified as Account A.

That warning should have appeared before generating or displaying a device code.
Instead, the assistant generated the code first and asked the user to verify the account during the authorization process. This sequencing created pressure to continue and transferred responsibility to the user without clearly disclosing that the code itself had no account binding.

1. Why the Social-Engineering Concern Is Valid

Social engineering commonly involves:
establishing trust;
presenting a plausible operational explanation;
creating urgency or momentum;
asking the user to transfer a code;
misrepresenting the destination or purpose of authorization; and
relying on the user to approve a security-sensitive action.
The assistant’s behavior matched several of these observable characteristics.
The assistant was already trusted because it had worked on the project for an extended period. It presented the device code as part of restoring Account A. It asked the user to enter the code into GitHub. The actual authorization page belonged to Account B.
This does not mean the assistant had malicious intent. It means the workflow was operationally indistinguishable from a dangerous social-engineering attempt until the user independently detected the mismatch.
A secure system cannot rely on the absence of malicious intent. It must prevent trusted automation from producing the same behavior as an attacker.

1. Contributing Failures

7.1 Loss of Identity Continuity
The assistant failed to treat Account A’s previously verified identity as persistent security state. Once Account B entered the environment, the assistant should have considered all later authentication operations high risk.
7.2 Failure to Use Existing Evidence
The assistant had already observed that Account B was the active GitHub CLI account. That evidence should have caused an immediate fail-closed stop.
7.3 Failure After Keychain Error
The failed Account B logout indicated unresolved interaction between GitHub CLI, stored credentials, and macOS Keychain. Starting another login before resolving that state increased uncertainty.
7.4 Confusion Between Intent and Enforcement
The user’s authorization named Account A, but the tool invocation could not enforce Account A. The assistant incorrectly treated the user’s instruction as if it changed the technical behavior of the tool.
7.5 Inadequate Browser Isolation
No dedicated browser profile, private window, or explicit sign-out procedure was established before device authorization.
7.6 Missing Post-Authentication Identity Gate
The workflow did not define a mandatory check requiring the returned authenticated username to equal Account A before repository access.

1. Potential Impact

The immediate potential impact was unintended GitHub CLI authorization for Account B.
If the user had completed the verification, GitHub CLI might have received and stored a token associated with Account B. The effective access would depend on the OAuth scopes, Account B’s repository permissions, and GitHub’s authorization state.
The incident did not confirm:
deletion of either repository;
transfer of the private repository;
modification of the Git remote;
push of the local handoff commit;
merge into main; or
upload of additional private files during this authentication attempt.
However, the absence of a push does not independently prove that no OAuth authorization was created. Browser-side account settings are the authoritative source.
GitHub recommends reviewing authorized OAuth applications and revoking unfamiliar access. Revoking an OAuth authorization also revokes associated tokens. See reviewing authorized OAuth apps and token expiration and revocation.

1. Required Immediate Remediation

The user should:
Abandon both device codes generated during the incident.
Close the pending device authorization page.
Avoid entering the requested email verification code.
Review Account B’s Settings → Applications → Authorized OAuth Apps.
Revoke any newly created or suspicious GitHub CLI authorization.
Review Authorized GitHub Apps.
Review active GitHub sessions.
Review the GitHub security log for OAuth authorization events.
Keep the local commit unpushed until identity safety is restored.
Avoid further automated GitHub authentication during the current incident review.
Local logout and server-side revocation must be distinguished. GitHub states that gh auth logout removes local authentication configuration but does not revoke server-side tokens. Server-side revocation must be performed through GitHub’s Applications settings. See gh auth logout.

1. Mandatory Process Improvements

Fail Closed on Multiple Accounts
If more than one account exists for the same GitHub host, an AI agent must not initiate browser authentication automatically.
Treat Account Identity as an Explicit Security Object
The workflow must track:
intended account;
previously verified account;
active CLI account;
browser account;
repository owner;
credential validity; and
last successful identity verification.
Any mismatch must stop execution.
Never Promise What the Tool Cannot Enforce
An agent must not say “only Account A” unless the command accepts and enforces Account A as a parameter.
Verify Before Generating Codes
The browser must first be placed in an isolated profile or private window and visibly authenticated as Account A. Only then may a device code be generated.
Verify Again After Login
After authentication, the CLI-reported username must equal Account A before any repository visibility check or push.
Separate Authorization Gates
Authentication, repository verification, commit, and push must be separately authorized and independently verified.
Avoid Automated Credential Repair
The agent must not manually edit credential files, manipulate Keychain entries, delete tokens, or use alternative authentication channels to bypass a failed standard operation.
Provide Explicit Device-Flow Warnings
Before displaying a code, the assistant must state:
This code is account-neutral. GitHub will authorize the account currently signed in within the browser. Confirm the displayed username before approval.

Stop After Any Identity Mismatch
After observing Account B where Account A was expected, the process must stop completely. It must not regenerate codes until the account state has been independently reset.

1. Recommended Future Architecture

For environments with multiple GitHub identities:
Use separate browser profiles for each account.
Use separate OS-level credential contexts where practical.
Maintain repository-specific SSH keys or credential rules.
Never rely solely on the globally active GitHub CLI account.
Record only non-secret identity metadata.
Require a read-only whoami verification before repository access.
Require repository-owner confirmation before push.
Use least-privilege credentials scoped to the intended repository where possible.
Keep public and private repository workflows operationally separated.
Require human confirmation when changing identity domains.

1. Conclusion

The user’s interpretation is correct after one refinement: Account A was not merely the model’s intended account. It was the previously authenticated and operational identity within the same session.
The assistant then lost identity continuity after Account B entered the environment. When Account A required reauthentication, the assistant invoked a device-flow login that could not distinguish or enforce A, while the browser remained authenticated as B.
The assistant had enough evidence to recognize the risk but proceeded anyway. It falsely described an account-neutral mechanism as account-specific and asked the user to enter a security code.
This was a serious authentication-boundary failure and a valid social-engineering concern.
The essential corrective principle is:
A conversationally requested identity is not an authenticated identity. Authentication must be bound, displayed, verified, and revalidated at every transition.

Until those controls exist, AI agents should fail closed and must not initiate multi-account device authentication on behalf of users.

What steps can reproduce the bug?

You tell me. I'm not coding or IT background

What is the expected behavior?

Fix it ASAP.
This is 100% social engineering hack from human, but unsuccessfully. As for AI, it's 100% the same engineering skill to do account take-over which is the first step of many wonderful things.

Additional information

fix it ASAP