Codex opt out of training, and what to verify

Start with the plan you are on

Whether you need to opt out of training for Codex depends almost entirely on which agreement your access sits under, and the answer differs between consumer subscriptions, API usage, and business or enterprise agreements. Business-tier agreements generally state that customer content is not used to train models by default, while consumer plans put the control in a data controls setting the individual user can toggle.

We are deliberately not quoting exact menu paths or policy clauses here, because these change and a stale instruction is worse than none. Read the current data usage page for your specific plan and, if you are on a business agreement, read the agreement itself rather than the marketing summary. If your company has a legal or procurement function, this is a ten-minute question for them, and they will want the answer on record anyway.

The setting is the smaller half of the problem

Opting out governs what the provider may do with what you sent. It does nothing about what you sent. Those are separate risks and only one of them has a toggle.

In practice, the leaks we see in client codebases are mundane:

• A .env file sitting in the working directory, read by an agent while it looks for config.
• Production database dumps left in a fixtures or scratch directory.
• Real customer records pasted into a test file to reproduce a bug.
• Private keys committed years ago, still in the tree, still readable.
• An agent running a command that prints environment variables into the transcript.

None of that is fixed by a training opt-out. All of it is fixed by an afternoon of housekeeping and a rule about what lives on developer machines.

Checks worth running before you sign off

Three concrete things. First, confirm what the agent can read. Run a session in a clean checkout and ask it to list every file it considers in scope. You will usually find something you did not expect.

Second, put secrets out of reach rather than out of mind. Keep them in a secret manager and inject at runtime, so there is no file to read. Add local-only paths to your ignore rules and check that the agent respects them, rather than assuming.

Third, decide which repositories are off limits entirely. Most organisations have two or three where the answer should be no regardless of settings, usually anything holding regulated customer data. Write that list down and tell people. An unwritten rule is not a control.

What to tell your engineers

Say the plain version: we have opted out where the plan allows it, here is the evidence, and separately, do not put customer data or credentials where an agent can read them. Both halves. Teams that only communicate the first half end up with engineers who believe the setting protects them from their own habits.

Also tell them what happens on a personal account. An engineer using a consumer subscription on a work machine is under a different agreement than the one your legal team reviewed. That gap is worth closing with licences rather than with policy.

Do this next

Confirm the current data usage terms for your exact plan today and save a dated copy. Then run the clean-checkout file-scope test on your most sensitive repository. The second one usually produces more work than the first.

If you want help putting this into practice, talk to us.