“Please contact your workspace admin to enable device code authentication” — the fix
Codex on a server forces device-code sign-in, and workspaces ship with it off, so headless logins fail until an admin flips one permission. What to send your admin, and what to do meanwhile.
This error means your ChatGPT account belongs to a workspace (Business, Team, or Enterprise), and device-code sign-in is a workspace permission that ships disabled. You can’t fix it from your side: a workspace owner or admin has to enable device code authentication in the workspace’s settings (as of mid-2026 it lives under the workspace’s permissions controls, labeled as enabling device code authentication for Codex), and OpenAI’s docs confirm the split plainly: “Enable device code login in your ChatGPT security settings (personal account) or ChatGPT workspace permissions (workspace admin).” Until the toggle flips, the server rejects every code, no matter how correctly you ran the flow.
Why you’re seeing it (and only on servers)
On a laptop, Codex signs in by popping a browser: no device codes involved. On a machine with no browser (an SSH session, a VPS, a container, CI), the CLI falls back to the device-code flow: it prints a short code, you approve it from a browser elsewhere. That flow is the one workspaces gate. The result is the inconsistency that fills the GitHub issues on this error: the same user signs in fine at their desk, then hits a hard wall from a server, purely because the environment changed the auth method. If you’re setting up a coding agent on an always-on box or connecting a ChatGPT subscription to OpenClaw, the server is exactly where you are, which is why this error finds people mid-setup.
What to send your admin
The request is small and specific: most admins just need to know the toggle exists. Something like: “I need device code authentication enabled for our workspace so Codex CLI can sign in on a headless machine. It’s in the workspace settings under permissions: the device code authentication option for Codex. It ships off by default; turning it on lets members approve CLI sign-ins from their own browser.” Two notes for the security review that may follow. First, the caution is real: device-code phishing, an attacker asking a victim to approve the attacker’s code, is why this ships off. Approvals should only ever be for codes you generated yourself, and OpenAI’s own guidance says never to share one. Second, the alternative isn’t “no server access”: it’s API keys, which have their own budget and controls but skip workspace sign-in entirely.
After the toggle flips
Rerun the sign-in on the server (codex login --device-auth for Codex CLI, or your tool’s device-code path) and approve the code from a browser that’s already signed in to the right ChatGPT account. Codes expire quickly, so one that sat while you emailed your admin is dead; start fresh. If the flow still fails on a personal account with no workspace involved, you’re looking at the other half of this pair: the personal Security-settings toggle, which you can flip yourself.
If your admin says no
A workspace that keeps device-code auth off is making a defensible call, and there’s no supported way around it with workspace credentials: the rejection happens server-side. Your options narrow to two: use an API key for server workloads (billing shifts from the seat to usage), or run the sign-in on a machine with a real browser and accept that the credential then lives there. What you shouldn’t do is hunt for a bypass. The gate is the workspace saying how its identity may be used, and tooling that respects that is tooling your security team will keep approving.