Codex inloggen: met je ChatGPT-account of een API-key, per interface

Per interface

Codex inloggen per interface: web, desktop-app, CLI, IDE en mobiel

Codex kent volgens de authenticatiedocumentatie twee inlogmethodes voor OpenAI-modellen: "Sign in with ChatGPT" voor toegang via je abonnement en "Sign in with an API key" voor betalen per gebruik. De desktop-app, de CLI en de IDE-extensie ondersteunen allebei voor lokaal werk. Codex cloud vereist altijd een ChatGPT-login. Bij een ChatGPT-login opent Codex een browservenster en stuurt de browser je credentials daarna terug naar de app of terminal.

Zoek je wel het goede Codex?

Wie in Google "codex inloggen" typt, krijgt vooral inlogpagina's van andere producten met dezelfde naam, zoals compliance- en projectportalen. Die hebben niets met OpenAI te maken. Deze pagina gaat over Codex van OpenAI, de coding-agent die in je ChatGPT-abonnement zit. Je herkent de echte inlogflow aan het domein: de browser stuurt je naar chatgpt.com of auth.openai.com, nooit naar een ander domein. Wat Codex precies is, staat in het woordenboek.

Codex cloud: inloggen, werkruimte kiezen, MFA

Voor de cloudversie installeer je niets. Je opent chatgpt.com/codex, logt in met je ChatGPT-account en kiest de werkruimte waarin je wilt werken. Omdat Codex cloud direct met je code werkt, eist OpenAI extra beveiliging: log je in met e-mail en wachtwoord, dan moet je eerst multi-factor authenticatie (MFA) instellen. Log je alleen in via Google, Microsoft of Apple, dan is MFA op je ChatGPT-account niet verplicht, maar wel aan te raden bij die provider. GitHub koppelen en environments inrichten staat op Codex cloud.

CLI en IDE-extensie delen hun login

De CLI en de IDE-extensie delen dezelfde opgeslagen login. Log je bij een van de twee uit, dan moet je bij de andere ook opnieuw inloggen. De downloadlinks voor de desktop-app en hoe je nep-apps herkent, staan op de Codex-app.

ChatGPT of API-key

ChatGPT-account of API-key: het verschil in kosten, functies en data

Je inlogmethode bepaalt meer dan je denkt: wie de rekening krijgt, welke functies je hebt en welke privacy-instellingen gelden. De documentatie zegt het letterlijk: bij een ChatGPT-login volgt Codex je werkruimte-permissies, rollen en de retentie- en residency-instellingen van je werkruimte. Bij een API-key volgt het de retentie- en data-sharing-instellingen van je API-organisatie.

Kies ChatGPT-login als je zelf met Codex werkt

Voor iemand die interactief codeert is de ChatGPT-login bijna altijd de betere keuze. Je betaalt een vast bedrag, je krijgt Codex cloud en GitHub-reviews erbij, en je hoeft geen budget te bewaken. Wat elk plan kost en hoeveel ruimte je krijgt, staat op wat Codex kost.

Kies een API-key voor scripts, CI en gedeelde machines

OpenAI raadt de API-key zelf aan voor geautomatiseerde workflows zoals CI/CD-jobs. De reden: een key hoort bij een project in je API-organisatie, je kunt hem los intrekken en je ziet het verbruik apart. Een key zet geen automatisch plafond, dus stel in je API-organisatie een budget in voordat je hem gebruikt. De maandelijkse API-credits van Pro en Business gelden niet voor Codex via een API-key, zie is Codex gratis.

Wissel je van methode, dan wissel je van privacyregime

Een developer die thuis met een API-key werkt en op kantoor met de Business-werkruimte, valt onder twee verschillende sets afspraken. Voor je verwerkingsregister onder de AVG zijn dat twee aparte verwerkingen. Hoe training, retentie en de zakelijke plannen uitpakken, staat op Codex privacy.

Terminal

codex login in de terminal: alle commando's op een rij

Zonder vlaggen opent codex login je browser voor de ChatGPT-login. Codex start daarvoor een kleine server op localhost (standaard poort 1455) die de login opvangt. Opent je browser niet vanzelf, dan print de CLI de link om zelf te openen. De commando's hieronder komen uit de CLI-referentie en de broncode.

Waarom de key via stdin moet

Je geeft de key niet meer als argument mee. De oude vlag --api-key stopt nu met de melding dat je moet pipen. Dat is bewust: een argument belandt in je shellgeschiedenis en in de proceslijst, een pipe niet. Zet de key dus eerst in een omgevingsvariabele of haal hem uit je wachtwoordmanager, en pipe hem dan door.

Een key wordt pas gecontroleerd bij je eerste opdracht

Na --with-api-key meldt Codex "API key saved. Authentication is checked when you send a request." Codex test de key dus niet bij het opslaan. Een typfout of een key zonder tegoed merk je pas bij je eerste prompt. Stuur daarom meteen een korte testopdracht, bijvoorbeeld:
codex exec "Zeg alleen: ok"
Krijg je een foutmelding, kijk dan in de tabel bij login werkt niet.

Een API-key aanmaken

Een key haal je in het OpenAI-dashboard. Maak hem aan in een apart project voor Codex, zodat je het verbruik los ziet en de key kunt intrekken zonder andere koppelingen te raken. Kopieer de key direct naar je wachtwoordmanager. Het dashboard toont hem maar één keer.

Voor CI: zet de key alleen op de Codex-stap

In pipelines gebruik je CODEX_API_KEY voor codex exec en codex review, inline op de stap die hem nodig heeft. De documentatie waarschuwt: zet OPENAI_API_KEY of CODEX_API_KEY niet als variabele voor de hele job als die job code uit de repository draait, want build-scripts en dependencies kunnen hem dan uitlezen. Voor GitHub raadt OpenAI de Codex GitHub Action aan; die staat op Codex installeren.

Zonder browser

Codex inloggen op een server, via SSH of in Docker

De gewone login opent een browser en wacht op een terugmelding op localhost:1455. Op een VPS, een Raspberry Pi of in een container is er geen browser, of blokkeert je netwerk die terugmelding. OpenAI noemt device code-authenticatie de voorkeursroute, met twee terugvalopties.

Terugvaloptie 1: de poort doorsturen via SSH

Kun je poorten doorsturen, dan werkt de gewone browserflow ook op afstand. Start vanaf je eigen machine:
ssh -L 1455:localhost:1455 gebruiker@server
Draai in die SSH-sessie codex login en open de geprinte link in de browser op je laptop. De terugmelding komt via de tunnel bij de server aan.

Terugvaloptie 2: je login kopiëren

Log in op een machine met browser, controleer dat ~/.codex/auth.json bestaat en kopieer dat bestand naar dezelfde plek op de server:
ssh gebruiker@server 'mkdir -p ~/.codex && cat > ~/.codex/auth.json' < ~/.codex/auth.json
Voor een container gebruik je docker cp naar de map .codex in de home van de container. Werkt je laptop met de keychain in plaats van auth.json, dan bestaat dat bestand niet en moet je eerst bestandsopslag instellen (zie waar je login staat).

Wanneer kopiëren niet verstandig is

Een gekopieerde auth.json is jouw identiteit op een andere machine. Iedereen met toegang tot die server werkt dan als jij, op jouw limiet. Gebruik het alleen op een server waar alleen jij bij kunt. Voor een gedeelde server of CI blijft een API-key de aanbevolen standaard; OpenAI documenteert daarnaast een geavanceerde route om een ChatGPT-login in CI te onderhouden.

Zakelijk

Codex inloggen met Business of Enterprise: SSO, werkruimtes en access tokens

In een zakelijke werkruimte is inloggen maar één laag. Lidmaatschap van de werkruimte bepaalt wie kan inloggen, je plek en rol bepalen welke functies je krijgt. ChatGPT Business heeft volgens de prijspagina SAML SSO en MFA; SCIM-provisioning en gesynchroniseerde groepen zitten er niet in, die horen bij Enterprise.

SSO via je eigen identiteitsprovider

Met SSO logt een medewerker in met zijn werkaccount in plaats van een los OpenAI-wachtwoord. Werk je met Microsoft 365, dan is Microsoft Entra ID meestal die provider. ChatGPT kan MFA niet werkruimtebreed afdwingen; OpenAI zegt dat je SSO en MFA via je identiteitsprovider moet afdwingen. Voor Codex cloud is dat extra belangrijk, omdat die direct aan je repositories zit. In de CLI merk je van SSO niets bijzonders: codex login stuurt je naar dezelfde browserlogin, alleen loopt die via je werkaccount.

Codex moet per werkruimte aanstaan

Een geslaagde SSO-login is geen toegang tot Codex. De werkruimte-eigenaar zet lokale toegang aan met Allow members to use Codex locally (of Allow members to use Codex and Work Locally, afhankelijk van de indeling) en cloudtoegang met Use Codex in the cloud. Staat dat uit, dan toont de browser "You do not have access to Codex" en meldt de CLI dat Codex niet is ingeschakeld voor je werkruimte.

Wisselen van werkruimte of account

Een aparte wisselknop heeft de CLI niet. Draai codex logout, dan codex login, en kies in het browservenster het andere account of de andere werkruimte. In de desktop-app en de IDE-extensie log je uit via het profielmenu. Chats en bestanden verhuizen niet mee: werk die in de ene werkruimte staat, zie je in de andere niet. Wie met zowel een privé-Plus als een Business-account werkt, controleert na het inloggen met codex login status en /status in welke omgeving hij zit.

Beheerders kunnen de route vastleggen

In config.toml of via managed configuration legt een beheerder vast hoe er ingelogd mag worden:
forced_login_method = "chatgpt"
forced_chatgpt_workspace_id = "id-van-je-werkruimte"
Komen de actieve credentials daar niet mee overeen, dan logt Codex de gebruiker uit en sluit af. Zo voorkom je dat iemand met een privé-account of een losse API-key in bedrijfscode werkt. Hoe managed configuration verder werkt, staat op Codex privacy.

Access tokens voor automatisering

Business- en Enterprise-werkruimtes kunnen Codex access tokens toestaan voor vertrouwde scripts, planners en private CI-runners. Een token hoort bij de medewerker die hem aanmaakt, in de beheerconsole onder Access tokens, en werkt met diens rechten in de werkruimte. Gebruik het alleen als je automatisering echt werkruimte-toegang nodig heeft; volstaat een Platform API-key, dan houdt OpenAI het bij die key.

Auth-bestand

Waar Codex je login opslaat: auth.json of de keychain

Na het inloggen bewaart Codex je credentials lokaal, zodat je niet elke sessie opnieuw hoeft in te loggen. Dat gebeurt in een plaintext-bestand op ~/.codex/auth.json of in de credential-store van je besturingssysteem. Bij een ChatGPT-login ververst Codex de tokens zelf voordat ze verlopen. Met de instelling cli_auth_credentials_store in config.toml kies je de opslag.

Behandel auth.json als een wachtwoord

Het bestand bevat access tokens. De documentatie is er stellig over: niet committen, niet in een ticket plakken, niet in een chat delen. Het risico zit zelden in je projectmap, want auth.json staat in je home-map. Het zit in dotfiles-repositories, in een Docker-image waarin iemand ~/.codex meekopieert, en in back-ups van je home-map naar een gedeelde schijf. Zet .codex/ daarom ook in de .gitignore van je dotfiles en sluit het uit van images.

Uitloggen trekt je login ook echt in

Bij codex logout probeert Codex eerst je refresh token bij OpenAI in te trekken en verwijdert daarna je lokale login, ook als dat intrekken mislukt. Een kopie van auth.json op een andere machine kan daarna geen nieuwe tokens meer ophalen. Ben je je laptop kwijt, wijzig dan bovendien je ChatGPT-wachtwoord en trek API-keys in het dashboard in.

Beheerders kunnen de opslag afdwingen

Via lokale authenticatie-eisen kan een beheerder cli_auth_credentials_store vastzetten, bijvoorbeeld op keyring. Gebruikers kunnen dat dan niet meer overschrijven in hun eigen config.toml of met een CLI-vlag. Voor een team met beheerde laptops is dat de manier om plaintext-tokens op schijf te voorkomen.

Login werkt niet

Codex login werkt niet: de foutmeldingen en wat je doet

Codex toont zijn meldingen in het Engels. De teksten hieronder staan zo in de broncode van de Codex CLI op 30 oktober 2026; waar ... staat, vult Codex zelf iets in. Werkt Codex helemaal niet meer terwijl je wel bent ingelogd, kijk dan eerst op Codex status of er een storing is of je limiet op is.

Kom je er niet uit? Verzamel eerst dit

Draai codex login status en codex doctor. Elke directe codex login schrijft daarnaast een apart logbestand, codex-login.log, in je logmap. Dat bestand vraagt support op als de browser- of device code-login faalt. Plak het nooit integraal in een openbaar issue zonder te controleren of er tokens of e-mailadressen in staan.

Windows en WSL

In PowerShell bestaat printenv niet; gebruik daar $env:OPENAI_API_KEY | codex login --with-api-key. Werk je in WSL, dan geldt de Linux-variant en staat auth.json in je Linux-home, los van een login in de Windows-app. Installatieproblemen op Windows staan op Codex installeren.

Valkuil

De grootste valkuil bij Codex inloggen: je login of API-key delen

Zoek je op "codex api key", dan staan tussen de resultaten diensten die je vragen een eigen key of gateway-key in Codex te zetten, of die toegang via een tussenpersoon verkopen. Daarmee loopt je code via een partij waar je geen verwerkersovereenkomst mee hebt. Het tweede patroon is dichterbij: een team dat één Plus-login deelt door auth.json rond te sturen, of een developer die zijn API-key in een prompt of Slack-bericht plakt.

Waarom het misgaat

Wie je auth.json heeft, werkt als jou: in jouw werkruimte, op jouw limiet en onder jouw privacy-instellingen. Op een privé-Plus-account betekent dat bovendien dat training standaard aanstaat, tenzij je het hebt uitgezet. Een gedeelde login laat geen spoor na van wie wat deed. Een gelekte API-key kost geld tot iemand hem intrekt, want een key heeft geen ingebouwd plafond.

Wat je in plaats daarvan doet

Geef elke medewerker een eigen plek in een Business-werkruimte en laat iedereen met zijn eigen account inloggen. Gebruik voor scripts een aparte API-key per project, met een budget en een duidelijke eigenaar. Zet in config.toml forced_login_method zodat bedrijfscode alleen via de werkruimte loopt. Is er toch iets gelekt, trek de key dan direct in het dashboard in en laat de eigenaar van de auth.json codex logout draaien.

Ons oordeel

Ons oordeel: zo regel je Codex-inloggen in een Nederlands team

Inloggen lijkt een klik, maar je kiest er je rekening, je functies en je privacyregime mee. Ons advies als trainer: kies het per type gebruik, niet per persoon, en leg het vast voordat de eerste developer zelf iets bedenkt.

De fout die we in trainingen het vaakst zien

Iemand volgt een Engelstalige tutorial van een jaar oud, logt in met een API-key en snapt daarna niet waarom Codex cloud en GitHub-reviews ontbreken. Of hij merkt het pas aan een factuur van het OpenAI Platform naast zijn Plus-abonnement. Controleer daarom bij elke nieuwe installatie met codex login status of er "Logged in using ChatGPT" staat. Staat er "API key configured", dan weet je dat je per token betaalt.

Nederlandse context: AVG en het privé-account

Het grootste privacyrisico zit niet in de techniek maar in welk account er inlogt. Een developer met een privé-Plus-account die aan klantcode werkt, valt onder consumentenvoorwaarden met training standaard aan. In een Business-werkruimte staat training standaard uit en bepaalt de beheerder de bewaartermijn. Leg dus vast dat bedrijfscode alleen via de werkruimte gaat, en dwing dat af met forced_login_method en forced_chatgpt_workspace_id. Meer over de AVG-kant staat in ChatGPT veilig gebruiken.

Een voorbeeld uit het MKB

Neem een webbureau met vijf developers op Microsoft 365. Ze nemen ChatGPT Business, koppelen SSO aan Entra ID en dwingen MFA daar af. Iedereen logt in de CLI in met codex login via zijn werkaccount. In config.toml, uitgerold via hun MDM, staan forced_login_method = "chatgpt", hun werkruimte-id en cli_auth_credentials_store = "keyring". De nachtelijke testjob in hun pipeline draait met een aparte API-key in een eigen project met een maandbudget. Gaat er iemand weg, dan haalt de beheerder hem uit de werkruimte en is zijn Codex-toegang daarmee ook weg. Wil je dat in één middag samen goed neerzetten, dan is een AI-werksessie daarvoor bedoeld.

Wanneer een API-key wel de betere keuze is

Heb je geen ChatGPT-abonnement nodig en gebruik je Codex alleen af en toe in scripts, dan is een API-key met een laag budget logisch. Je betaalt dan alleen wat je gebruikt. Zodra je Codex dagelijks interactief gebruikt of cloudtaken wilt, wint de ChatGPT-login. Hoe Claude Code dit regelt, staat op Claude-account en inloggen; beide tools naast elkaar op Claude Code vs Codex.