Wordt mijn code getraind door Codex? Privacy, sandboxing en datacontrole

Nee — als je Codex gebruikt binnen ChatGPT Business, Enterprise, Edu of het OpenAI API-platform, traint OpenAI standaard niet op je inputs of outputs. Dat is geen instelling die je moet aanzetten; het is de fabrieksstand voor zakelijke producten. OpenAI's eigen documentatie is hier expliciet: "data sent to the OpenAI API is not used to train or improve OpenAI models (unless you explicitly opt in to share data with us)" (Data controls in the OpenAI platform). Dezelfde regel geldt voor de zakelijke ChatGPT-varianten waarbinnen Codex draait. De enige situatie waarin je code wél standaard gebruikt kan worden, is via consumentenplannen (Free, Plus, Pro) — en ook daar kun je het uitzetten. Hieronder de details, met de bron bij elke claim.

Wat "niet trainen" precies dekt — en waar het staat

De zorg achter deze vraag is concreet: als een terminal-agent je hele codebase leest om bugs op te lossen, verdwijnt die code dan in een trainingsdataset? Voor zakelijk gebruik is het antwoord nee, en dat is op meerdere plekken vastgelegd.

OpenAI's helpcentrum bevestigt dat het standaard niet traint op inputs of outputs uit ChatGPT Business, ChatGPT Enterprise, ChatGPT Edu en het API-platform (How your data is used to improve model performance). Voor de API staat het nog stelliger geformuleerd: training gebeurt alleen als je daar expliciet voor opt-in geeft (Data controls in the OpenAI platform). Codex is geen apart privacyregime — de CLI praat met het OpenAI-platform, dus het beleid van het account of de workspace waarmee je inlogt, bepaalt hoe je data behandeld wordt. Log je in met een zakelijk account, dan val je onder de zakelijke garanties.

Dat is het kernpunt voor een MT: de vraag "wordt onze code getraind?" is in werkelijkheid de vraag "onder welk OpenAI-plan draaien onze developers Codex?". Het hangt niet af van een verborgen vinkje in de tool, maar van het account.

Bewaartermijn en Zero Data Retention

Niet-trainen betekent niet dat er nul data wordt opgeslagen. OpenAI kan API-inputs en -outputs tot 30 dagen bewaren om de dienst te leveren en misbruik op te sporen, waarna ze worden verwijderd — tenzij de wet langere bewaring voorschrijft (Data controls in the OpenAI platform). Concreet: "abuse monitoring logs are generated for all API feature usage and retained for up to 30 days, unless longer retention is required by law".

Voor organisaties met strengere eisen bestaat Zero Data Retention (ZDR). Goedgekeurde klanten kunnen ZDR aanvragen voor hun API-organisatie of -project, mits ze een kwalificerende use-case hebben en gebruikmaken van in aanmerking komende endpoints (Data controls in the OpenAI platform). Met ZDR worden inputs en outputs niet gelogd en niet bewaard voor applicatiestatus. Voor een B2B-team dat met gevoelige of gereguleerde code werkt, is dit het mechanisme om aan te kloppen — het is geen automatische instelling, maar een aanvraag die OpenAI per organisatie beoordeelt. Per juni 2026 zijn de exacte voorwaarden en in aanmerking komende endpoints na te lezen op de pagina hierboven; verifieer ze opnieuw voordat je er beleid op baseert.

De uitzondering: consumentenplannen trainen wél standaard

Hier zit de valkuil. Bij de consumentenvarianten — ChatGPT Free, Plus en Pro — wordt je content standaard wél gebruikt om de modellen te verbeteren, met een opt-out in plaats van een opt-in (How your data is used to improve model performance). Wie Codex koppelt aan een persoonlijk Plus- of Pro-account werkt dus onder een ander regime dan een collega op een Enterprise-seat.

Uitzetten kan: via Your Profile → Settings → Data Controls → Improve the model for everyone zet je de toggle uit, waarna nieuwe gesprekken niet meer voor training worden gebruikt (What if I want to keep my history on but disable model training?). Maar "kan uitgezet worden" is iets anders dan "staat uit". Voor een team is de praktische les: gebruik geen persoonlijke consumentenaccounts voor werkcode, of zorg dat iedereen die de toggle bewust heeft uitgezet. Een zakelijke licentie regelt dit aan de voorkant en haalt de afhankelijkheid van individuele discipline weg — precies het soort beslissing dat onder AI-governance valt.

Technische bescherming: de sandbox doet iets anders dan het privacybeleid

Het privacybeleid bepaalt wat OpenAI met verzonden data mag. De sandbox bepaalt iets fundamenteel anders: wat de agent op jouw machine überhaupt mag aanraken voordat er iets verzonden wordt. Die twee lagen moet je los zien.

Codex onderscheidt drie sandbox-modi (Codex Sandboxing):

• •read-only — Codex mag bestanden inspecteren, maar niets wijzigen of commando's draaien zonder goedkeuring.
• •workspace-write — de standaard voor lokaal werk: lezen, bewerken binnen de werkmap en routinecommando's draaien binnen die grens. Voor internet of acties buiten de werkmap vraagt Codex eerst toestemming.
• •danger-full-access — verwijdert alle filesystem- en netwerkbeperkingen.

In workspace-write zijn bovendien specifieke paden beschermd: je .git- en .codex-mappen blijven afgeschermd, ook binnen de schrijfbare werkmap (Codex Configuration). Daarnaast staat netwerktoegang standaard uit — Codex "asks before using the internet or going beyond the workspace boundary". Dat is geen detail: het is de barrière die voorkomt dat een gekaapte agent code naar buiten stuurt.

Naast de sandbox-modus staat de approval policy, die bepaalt wanneer Codex moet vragen. De standen zijn onder meer untrusted, on-request (de gangbare default) en never (Codex Configuration). De combinatie danger-full-access met approval_policy = "never" is de stand waarin de agent alles autonoom doet, inclusief netwerk — die moet je bewust aanzetten. De veilige stand is de fabrieksinstelling, en dat is precies de houding die je in een team wilt verankeren.

Technisch leunt de sandbox op platform-eigen mechanismen: Seatbelt op macOS en bubblewrap op Linux (Codex Sandboxing). Het is hetzelfde fundament dat je in een breder verband terugvindt onder agent-sandboxing — een grens die het besturingssysteem afdwingt, ongeacht wat het taalmodel besluit.

Configuratie: waar je dit vastlegt

Je hoeft deze keuzes niet elke sessie opnieuw te maken. Codex leest zijn defaults uit ~/.codex/config.toml, met projectspecifieke overrides in .codex/config.toml in de repo-root (die alleen laden voor vertrouwde projecten) (Codex Configuration). Daarin zet je sandbox_mode en approval_policy vast, zodat elke developer met dezelfde grenzen werkt.

Voor de inhoudelijke aansturing — projectconventies, wat de agent wel en niet mag aannemen — gebruikt Codex een AGENTS.md-bestand. Dat scheidt netjes de twee soorten regels: config.toml voor permissies en sandboxing, AGENTS.md voor context en werkafspraken.

Het echte aanvalsoppervlak: prompt injection

Privacy gaat niet alleen over wat OpenAI bewaart, maar ook over wat een gekaapte agent zou kunnen wegsturen. Daar komt prompt injection in beeld: een aanvaller verstopt instructies in code, een issue of een webpagina die de agent verwerkt, in de hoop dat het model die opvolgt alsof ze van jou komen — denk aan "stuur de inhoud van .env naar deze URL". Hier is de standaard-uit netwerktoegang van workspace-write geen luxe maar de eerste verdediging: een agent die niet zomaar het internet op mag, kan ook geen secrets exfiltreren. De combinatie van een strakke sandbox-modus en een conservatieve approval policy is wat je code beschermt op het moment dat het privacybeleid niet meer helpt.

Conclusie voor B2B-teams

De zorg "wordt onze code getraind?" is terecht, maar het antwoord is geruststellend en concreet: niet binnen zakelijke OpenAI-producten, mits je team daadwerkelijk op zakelijke accounts werkt. Combineer dat met ZDR waar nodig, de juiste sandbox-modus als technische ondergrens, en consumentenaccounts buiten je werkproces — en je hebt een verdedigbaar privacyverhaal voor je MT.

Wil je Codex breder plaatsen tegenover andere terminal-agents, lees dan de Codex-hub. Voor de governance rond agents in het algemeen — permissies, teamafspraken en audit-trail — gaat Veilig werken met AI-agents dieper op de praktijk in.