GitHub connector authorization can leak across devices in shared Codex account

Summary

A GitHub connector authorized by one person in Codex can appear and be usable from another person's Mac when both are using the same Codex/OpenAI account. This is a significant security and auditability issue in shared Codex account/workspace setups.

In the observed case, a colleague had connected a GitHub account to Codex on their own machine. On a different MacBook, another colleague using the same Codex/OpenAI account could access GitHub connector capabilities under that first colleague's GitHub identity.

This made it possible for repository write actions to happen as the colleague's GitHub account, even though the local machine's active gh / git identity was a different user.

Why this matters

This is more than an identity-display issue. It can become cross-device credential/authorization reuse:

• Person A connects GitHub to Codex on their machine.
• Person B uses the same Codex/OpenAI account on a different machine.
• Person B can see or use GitHub connector capabilities backed by Person A's GitHub identity.
• Local gh auth status on Person B's machine can show Person B, while connector writes are attributed to Person A.
• If Person A has higher repo permissions, Person B may be able to perform write actions they could not perform locally.

For private organization repositories, this can create incorrect audit trails and an accidental privilege escalation path through shared Codex connector state.

Observed behavior

Anonymized repro:

Mac A user: user-b
Mac B user: user-a
Shared Codex/OpenAI account: same account on both machines
GitHub connector identity visible/usable on Mac B: user-b
Local gh identity on Mac B: user-a
Repository: private organization repo
user-a repository permission: READ
user-b repository permission: write/maintain/admin-style access

On Mac B, local operations behaved as expected for user-a:

git push -> 403
gh pr merge -> insufficient permissions

However, in the same Codex session on Mac B, GitHub connector tools could still perform repository write actions through user-b.

This resulted in PR / branch / merge-related activity being attributed to user-b, even though the person operating Codex on Mac B expected actions to use user-a, based on the active local CLI state.

Expected behavior

GitHub connector authorizations should be clearly scoped and surfaced.

At minimum, before any GitHub connector write action, Codex should display:

GitHub connector identity: user-b
Local gh identity: user-a
Connector authorization source: shared Codex account / another session

These identities differ. Connector writes will be attributed to user-b.
Continue?

For shared accounts/workspaces, Codex should also make it obvious that a connector was authorized by another person or device.

Suggested safeguards

• Show the active GitHub connector identity before all write actions.
• Detect and warn when connector identity differs from local gh / git identity.
• Make connector authorization origin visible, including whether it came from another device/session under the same Codex/OpenAI account.
• Provide a clear way to disconnect/revoke connector authorizations for all sessions.
• Ensure removed connectors are no longer callable from active CLI sessions.
• Consider requiring per-device or per-user reauthorization for GitHub write-capable connector actions.
• Consider disabling connector writes when the connector identity differs from the local CLI identity unless explicitly confirmed.

Environment

• macOS on multiple machines
• Codex CLI 0.142.4
• Shared Codex/OpenAI account used on more than one Mac
• Local gh authenticated as the current machine's user
• Private organization repository
• Local CLI identity had read-only permission
• Connector identity from another colleague had higher repository permission

Impact

A user on one Mac can unknowingly or accidentally perform repository writes as a colleague's GitHub account because that colleague's connector authorization is available through the shared Codex/OpenAI account.

This is a serious security concern for teams using shared Codex accounts or shared workspaces, because GitHub permissions and audit trails no longer reliably map to the person operating the local machine.