Does Codex Train on Your Data? Cloud, Workspace, and API Rules
Codex data-use rules depend on the route. Codex Cloud inspects selected repositories and executes tasks in OpenAI-managed workspaces. Business, Enterprise, and Edu workspace data is excluded from model training by default. Direct OpenAI API data is also excluded unless the customer opts in, while retention depends on abuse-monitoring settings and endpoint state. A useful approval names the execution surface, account, repository, retention control, connected services, and training rule.
Does Codex train on your data? OpenAI says business data in Business and Enterprise workspaces is excluded from model training by default. The same applies to Edu workspaces. The OpenAI API also excludes submitted data from training unless a customer opts in. Those statements cover different routes. Codex Cloud reads selected repositories and runs tasks in hosted workspaces. Local Codex can use a ChatGPT workspace sign-in or an API credential. Training defaults follow the applicable account or API organization, while retention and connected-service access need separate review.
TL;DR
- Codex Cloud inspects selected repositories and runs tasks in OpenAI-managed cloud workspaces, so repository scope and environment access belong in the approval record. Connections belong there too.
- Data from Business and Enterprise workspaces is excluded from OpenAI model training by default. The same applies to Edu workspaces. Confirm the actual workspace and any opt-in data-sharing path.
- OpenAI API data is excluded from training unless the customer opts in, but default abuse-monitoring logs may retain prompts and responses for up to 30 days.
- DeepInspect can enforce policy on supported local or API requests routed through its HTTP boundary. It does not govern hosted Codex Cloud execution.
Codex Cloud receives repositories and task context
OpenAI's Codex Cloud documentation says a user chooses repositories and creates or selects a cloud environment. Codex inspects the project, installs dependencies and tools, tests the workflow, then runs each task in its own workspace. The environment can also receive access to package registries and APIs as well as private services through configured network destinations and credentials.
That data path is broader than a single prompt. Repository files and setup instructions can enter or remain in the hosted work surface. The same applies to dependency metadata and task messages, plus test output and changed files. Connected services may add more content under their authorized scopes.
An approval should name the repository and branch scope. It should also record the workspace plan and environment, network destinations and credentials, plus retention settings and the responsible owner. The OpenAI enterprise security boundary covers the surrounding controls. Codex-specific review adds the repository and execution details.
Does Codex train on your data in a managed workspace
OpenAI's Work Cloud security documentation says data from Business and Enterprise workspaces is encrypted in transit and at rest and is not used to train OpenAI models by default. The same applies to Edu workspace data. It also explains that Work and Codex share core execution and isolation mechanisms. Tools and permissions can vary by surface and configuration. Administrative controls and retention can vary too.
For local Codex signed into one of those managed workspaces, record the tenant and account class. Add the authenticated user and administrative settings. Confirm any feedback or data-sharing option that can create an exception to the default. A developer saying "I used my company login" supplies too little evidence because the account could belong to another workspace or use a personal surface.
I would reject a training review based on the Codex product name alone. The useful evidence is a screenshot or export that shows the workspace identity beside the relevant data control, with the review date visible.
Direct API use has its own training and retention rules
OpenAI's API data controls documentation says data sent to the API has been excluded from training since March 1, 2023, unless the customer explicitly opts in to share it. A local Codex client authenticated with an API credential follows that API organization and project route rather than a ChatGPT workspace sign-in.
Training exclusion leaves storage questions open. By default, OpenAI generates abuse-monitoring logs that may contain prompts and responses plus derived metadata, with retention for up to 30 days. Eligible approved customers can configure Modified Abuse Monitoring or Zero Data Retention. OpenAI also stores application state for some capabilities because those features need state to perform the request.
Record the API organization and project. Add the credential owner and data-sharing status, then record the abuse-monitoring control and endpoint. Include application-state behavior. The ChatGPT training-data guide explains the adjacent consumer and managed-workspace boundaries without substituting them for API evidence.
Training, retention, and access need separate decisions
A no-training commitment governs one provider use after data arrives. It says little about which files Codex can read, which commands it can run, how long task state remains available, or which connected account can write to another system. Put those questions in separate review fields.
For Codex Cloud, inspect repository selection and environment configuration. Review internet destinations and network secrets. Check connected-account scopes and the places where task state or results are saved. For local Codex, inspect local file permissions and managed configuration. Inspect external services too. For direct API use, inspect credential custody and endpoint storage behavior.
The approval record should also name prohibited data classes. A repository can contain secrets, customer exports, incident records, or regulated data even when the task prompt contains none of them. The assembled context is the unit that reaches the model. The guide to preventing data leaks to ChatGPT covers classification before transmission.
Route evidence makes the default enforceable
A useful Codex record names the execution surface first. It identifies hosted Codex Cloud or a local client. For a local client, it records whether authentication uses managed workspace sign-in or an API key. It then attaches the account or organization, repository scope, approved data classes, training rule, retention configuration, enabled connections, policy owner, and review date.
Add change triggers for a workspace migration, API-project change, new repository, altered network access, data-sharing opt-in, retention change, or new connected service. Reopen the review when one occurs. Preserve the earlier decision so an auditor can see which rule applied when a task ran.
For customer-controlled HTTP routes, a per-request record can bind the authenticated caller to the destination. It can record content classification alongside them. It can also capture the policy version and outcome before the provider receives the request. That evidence proves route use. Provider-side training remains a contractual and vendor-assurance fact.
DeepInspect
DeepInspect can inspect supported local Codex or direct API traffic when the authenticated HTTP model request is deliberately routed through it. It can enforce destination and data policy, then preserve a per-decision record before OpenAI receives the content.
Hosted Codex Cloud execution remains outside that boundary. DeepInspect cannot see repository processing, cloud workspace state, local commands, or connected-service actions merely because Codex initiated them. Use provider controls for those surfaces and reserve request-boundary policy for traffic the enterprise actually routes. Book a technical deep dive at deepinspect.ai.
Frequently asked questions
- Does Codex Cloud train on private repositories?
For Business, Enterprise, and Edu workspaces, OpenAI says workspace data is excluded from model training by default. Codex Cloud still inspects selected repositories and processes them in hosted workspaces. Verify the actual workspace, data-sharing settings, repository scope, retention, and connections.
- Does local Codex train on company code?
The answer follows the authentication route. A local client signed into a managed Business, Enterprise, or Edu workspace receives that workspace's default training exclusion. A client using an API key follows the API organization's no-training default and any explicit opt-in.
- Does an OpenAI API key prevent training?
OpenAI says API data is excluded from model training unless the customer opts in. The key alone proves none of the surrounding settings. Record its organization and project, then verify data sharing, abuse-monitoring controls, endpoint behavior, and application-state storage.
- Is no training the same as Zero Data Retention?
No. Training use and retention are separate. Default API abuse-monitoring logs may contain customer content for up to 30 days. Zero Data Retention is an approved API control that changes logging and some endpoint behavior, subject to documented limitations.
- Can an AI gateway verify OpenAI's training process?
A gateway can verify the routed request, caller, destination, data class, policy version, and enforcement outcome. OpenAI controls data use after receipt. Vendor assurance and contract review verify the provider commitment.