Security Feature Request: Enterprise-Grade OAuth Session & Token Management for Codex and OpenAI Developer Tools
Summary
OpenAI has built an excellent OAuth authentication flow for Codex CLI by allowing users to authenticate directly with their ChatGPT account. However, the current implementation lacks a critical security capability that is considered standard across modern developer platforms.
Once an OAuth authorization has been issued, users currently have no ability to inspect, manage, audit, or selectively revoke those authorizations.
For developers running Codex across multiple workstations, cloud servers, VPS instances, CI/CD runners, Docker containers, WSL environments, or remote machines, this creates a significant operational and security risk.
This request is not primarily about convenience—it is about incident response, account security, and administrative control.
Current limitations
Today, users cannot determine:
- Which devices currently have an active OAuth authorization.
- Which servers are still authenticated.
- Whether an OAuth token issued months ago is still valid.
- Whether an old VPS still has access.
- Whether a compromised machine is continuing to authenticate successfully.
- Which authorizations are actively being used.
There is currently no interface to:
- list active OAuth authorizations;
- inspect issued OAuth tokens;
- view authorization history;
- revoke one specific authorization;
- revoke all Codex OAuth authorizations;
- configure authorization lifetime;
- receive notifications when new authorizations are created.
Real-world security scenario
Imagine the following situation.
A developer authenticates Codex on:
- desktop workstation;
- laptop;
- home server;
- office workstation;
- several VPS instances;
- CI runner;
- Docker container;
- Raspberry Pi;
- temporary cloud VM.
Months later, one VPS becomes compromised.
The developer immediately changes the OpenAI password.
However, they now face several unanswered questions:
- Is the OAuth token on that VPS still valid?
- Which machines currently possess active authorizations?
- Can the attacker continue using Codex?
- Which authorizations should be revoked?
- Which systems are still trusted?
At the moment, the answer to every one of these questions is effectively “the user cannot determine.”
This significantly complicates incident response.
Security implications
From a security perspective, the current model introduces several risks.
Lack of visibility
Users cannot audit existing OAuth authorizations.
Without visibility, it is impossible to know the actual attack surface.
No selective revocation
If only one server is compromised, the user should not be forced to invalidate every trusted environment.
Selective revocation is an industry-standard capability.
Incident response becomes guesswork
Modern security practices rely on rapid containment.
Without authorization management, containment becomes:
- manual;
- incomplete;
- uncertain.
Long-lived authorizations
OAuth authorizations may remain active for extended periods.
Users have no method to discover forgotten or abandoned authorizations.
Enterprise compliance
Organizations often require:
- device inventory;
- audit trails;
- authorization history;
- access revocation;
- security reviews.
Current functionality makes compliance significantly more difficult.
Suggested solution
1. OAuth Sessions dashboard
Add a dedicated page such as:
Settings
→ Security
→ OAuth Applications
or
Developer Sessions
2. Per-authorization information
Each authorization should display:
- Device name
- Hostname
- Operating system
- Optional user-defined label
- First authorized
- Last used
- Last IP address (or approximate location)
- OAuth client
- Authorization status
- Token expiration
- Scopes granted
3. Individual revocation
Users should be able to revoke exactly one authorization.
Example:
✓ Desktop
✓ Laptop
✓ Raspberry Pi
✕ Old VPS
without affecting any other device.
4. Global revocation
Provide:
“Revoke all Developer OAuth Sessions”
This is critical during suspected account compromise.
5. Authorization expiration
Allow optional expiration policies:
- 30 days
- 90 days
- 180 days
- Never
Organizations could enforce expiration.
6. Authorization notifications
Send email notifications when:
- a new OAuth authorization is created;
- a new device appears;
- a previously unseen country is used;
- a revoked authorization attempts to reconnect.
7. Authorization history
Maintain an audit log containing:
- authorization created;
- authorization revoked;
- last activity;
- failed authentication;
- client version;
- approximate geographic region.
8. Device naming
Allow users to rename authorizations:
“Home Server”
“Ubuntu VPS”
“MacBook Pro”
“Dell Precision”
rather than anonymous entries.
9. Risk indicators
Display warnings such as:
- inactive for 180 days;
- unusual location;
- never used again after creation;
- multiple simultaneous locations.
10. API support
Expose OAuth authorization management through the OpenAI API.
This would allow organizations to:
- automate audits;
- revoke compromised systems;
- integrate with SIEM platforms;
- enforce security policies.
Benefits
Implementing these capabilities would provide:
- significantly improved security;
- faster incident response;
- reduced attack surface;
- enterprise readiness;
- better compliance support;
- greater user trust;
- easier management of large developer environments.
Why this matters
Codex is increasingly being used on servers, cloud infrastructure, containers, remote development environments, CI/CD systems, and automation platforms.
As adoption grows, OAuth authorization management becomes a core security requirement rather than an optional feature.
Platforms such as GitHub, Google, Microsoft, GitLab, Atlassian, Slack, and many identity providers already provide visibility into authorized devices or OAuth applications.
OpenAI is rapidly becoming part of developers’ production infrastructure, and comparable authorization management capabilities would greatly strengthen the platform.
Thank you for considering this request.