Your test output may reveal more than your prompt.
You ask Codex to fix a failing test, and it reads a log containing real customer addresses. You didn’t intentionally upload a customer list. The agent still obtained personal data through an ordinary development task.
OpenAI Codex and GDPR need a review of that complete workflow. I’ll show you how to check your account, training controls, local permissions, and regional model route. You’ll also separate cloud environments from local work.
For everyday operation, see my Codex commands guide. The steps below focus on confidential projects and client data.
- Match the account and DPA to your use. Personal accounts have separate model-training and environment controls.
- Constrain local commands with permission profiles. MCP, browsers, model requests, and cloud tasks need their own checks.
- Regional storage, regional inference, and ZDR apply within specific scopes. An API key doesn't establish those guarantees.
1. Map the data paths before configuring Codex
A local app can execute development tools on your machine while using a hosted model. The model receives the prompt and selected context needed to answer. Local execution alone doesn’t establish local processing.
I’d sanitize the working copy before enabling the agent. Replace real records with fictional fixtures and keep production credentials outside its accessible environment. Check logs as carefully as source files.
If you’re still choosing an agent, see the Claude Code and Codex comparison.
The Codex permissions documentation separates the following control areas. Your assessment should do the same.
Separate Codex control areas. Documentation checked in October 2026.
Filesystem isolation limits what a process can collect. Your provider contract determines the permitted handling of transmitted content. Review that contract before adjusting the client.
2. Check the commercial contract and retention scope
For team use, I’d choose a centrally approved account and organization. This makes access and contractual responsibility easier to document than unrelated personal subscriptions.
OpenAI doesn’t train on Business, Enterprise, or Edu content by default.
The API also defaults to no training on customer data. Retention still needs its own assessment.
The OpenAI Data Processing Addendum is incorporated into the relevant Services agreements. Confirm that your access falls within that contractual scope.
Schedule 1 doesn’t envisage planned transfers of sensitive data, unless users unexpectedly include it in unstructured content. Keep these contents out of prompts, logs, and fixtures.
The schedule calls for safeguards proportionate to the risk, including access restrictions and access records. Confirm the specific agreement and legal approval before processing such data.
Review the subprocessor list alongside the permitted data and purpose.
Client work may introduce additional contractual restrictions. Your provider agreement doesn’t automatically authorize every subcontracting arrangement or every type of client data.
A DPA doesn’t establish the lawful basis for your own processing. Record the purpose and basis, applicable information duties, and procedures for access, rectification, and erasure. The German supervisory authorities’ AI guidance also calls for a prior risk assessment. A likely high risk generally requires a data protection impact assessment under Article 35 GDPR.
The API’s data controls documentation distinguishes abuse monitoring logs from application state. Default security logs can be retained for up to 30 days. Stateful features may create separate stored data.
Zero Data Retention requires approval and compatible features. If your project requires limited retention, verify the actual endpoint and configuration. Then configure the client’s optional data paths.
3. Review both training controls and local analytics
On a personal ChatGPT account, open ‘Settings > Data controls’ and disable ‘Improve the model for everyone’. That setting also applies to new Codex tasks.
Next, review ‘Include environments’ in Codex settings. It controls a separate use of environment data. The general opt-out doesn’t change it, as OpenAI explains in its data controls help.
An opt-out doesn’t retroactively delete previously submitted content.
Voluntary feedback can make the entire associated conversation available for model improvement despite a training opt-out. Don’t submit that feedback for confidential tasks, including through thumbs-up or thumbs-down controls.
Switching agents requires a fresh review of the controls. The Claude Code privacy guide covers its different configuration.
The local client has additional controls in ~/.codex/config.toml. These entries follow the configuration reference. Update existing sections rather than creating duplicate TOML tables.
[analytics]
enabled = false
[feedback]
enabled = false
[history]
persistence = "none"The history setting covers history.jsonl rather than every possible session file.
feedback.enabled disables the local /feedback feature. It doesn’t block other feedback routes in ChatGPT or on the web.
Provider retention and cloud transcripts remain separate. Include local files and backups in your device policy.
These settings limit optional data use. Commands running on your computer still need enforceable access restrictions.
4. Constrain local commands with a permission profile
Starting in a repository doesn’t automatically prevent access to nearby directories. An explicit filesystem policy gives you a boundary you can test.
Codex documents named permission profiles as a beta feature. Verify support in your client version.
Place the assignments near the top of ~/.codex/config.toml, before any tables. Add the profile sections below them.
Without managed allowed_permission_profiles, a loaded sandbox_mode setting or --sandbox launch selects the older sandbox instead of the permission profile. That managed allowlist is the documented exception.
Remove legacy sandbox_mode and sandbox_workspace_write settings from every loaded configuration and selected profile.
Launch without --sandbox or a protection bypass. Setting approval_policy to ‘on-request’ requires confirmation when Codex requests execution outside the sandbox.
approval_policy = "on-request"
default_permissions = "project"
[permissions.project]
extends = ":workspace"
[permissions.project.filesystem]
glob_scan_max_depth = 3
":root" = "deny"
":minimal" = "read"
":tmpdir" = "deny"
":slash_tmp" = "deny"
[permissions.project.filesystem.":workspace_roots"]
"**/.env" = "deny"
"**/.env.*" = "deny"
[permissions.project.network]
enabled = falseThe profile inherits :workspace rules for every effective runtime workspace root and enabled profile-defined root. Check any additional directories. It adds restrictions for temporary paths and matching secret files.
:minimal remains a read exception for common tool paths selected by Codex for the platform and runtime. It isn’t an exhaustive allowlist you supplied. Check its effective scope with your client version.
default_permissions selects only the default profile. Higher configuration layers can add or replace profile entries. For team policies, define profiles in managed requirements.toml and set allowed_permission_profiles. Omitted profiles, including built-ins, are then denied. This control requires Codex 0.138.0 or later.
On Linux, WSL, and native Windows, glob_scan_max_depth limits pattern scanning before sandbox startup. Matching deny-glob paths are collected ahead of time. The example depth of 3 must fit your project. Deeper files need an appropriate depth or explicit path rules.
A secret file created or moved afterward isn’t demonstrably protected by that earlier scan. Restart after such changes. Test existing files and a path created during the test separately.
Higher values add scanning work. Test read and write denials with fictional .env files on your actual platform.
If a tool fails, identify the specific missing path and grant only the necessary access.
Repeat that test rather than restoring unrestricted access across the machine.
Network rules have the same limited scope. Domain rules additionally require Codex’s active network proxy. An allowlist in this profile doesn’t establish a firewall for every Codex capability.
Your team needs to understand those boundaries and exceptions. The EU AI literacy guide helps with training planning.
The test checks what commands can collect. The provider route still determines where the permitted model context goes.
5. Verify storage and inference regions separately
Data residency concerns storage in an agreed region. Inference residency concerns model processing. Confirm both when your project requires European processing.
The ChatGPT residency documentation covers eligible Enterprise and Edu workspaces. It supports the Codex app and CLI while excluding Codex Web.
The documented European scope includes the EEA and Switzerland. System data, some processing stages, and third-party services can fall outside it. Check the actual workspace and feature exclusions.
For API access, verify the eligible project, regional endpoint, and supported model. Follow the API residency conditions rather than assuming a general endpoint chooses Europe automatically.
Azure provides a separate contractual and operational route through Codex’s custom provider configuration.
Microsoft distinguishes Global, DataZone, and geographic deployments. The resource location alone doesn’t establish the inference location.
Check the exact zone and Azure data conditions, including feature-specific storage.
Gateways such as EUrouter introduce another contract and routing layer. Its Responses API describes the interface, while retention and fallback need their own review.
Cursor Cloud Agents need separate approval if your team uses them too. The Cursor privacy guide covers their storage and networking paths.
You can also keep model inference on your own machine. That requires checking the selected model and every enabled online capability.
6. Separate local models from cloud environments
Ollama can run a downloaded model locally and connect it to Codex. The Ollama integration creates a dedicated profile through this command.
ollama launch codexSelect a genuinely local model rather than a hosted cloud model. Then inspect the tools enabled in that profile. A local inference process doesn’t make every tool offline.
Ollama’s integrated web search can run online even with local models.
Its documentation gives this command for disabling search in the generated profile.
codex --profile ollama-launch -c 'web_search="disabled"'For an isolated local workflow, also assess telemetry, MCP, connectors, and network access. Each introduces its own processing or transmission boundary.
Codex cloud environments move work in the other direction. They can include repositories, prepared filesystems, dependencies, and credentials. Your local permission profile doesn’t establish their access policy.
Connect only approved repositories and limited test credentials. Check who can use the environment and how its data is removed. Then test the selected workflow end to end.
7. Validate the approved workflow with fictional data
Use a small test repository with recognizable fictional records. Place another harmless file outside the approved access area. Real credentials aren’t needed to demonstrate an access failure.
Test the actual account and client profile your team plans to use. Record these checks individually.
- Confirm the organization, model provider, and active configuration.
- Check permitted project work and blocked filesystem access.
- Test command networking and each external integration separately.
- Inspect the local transcript and history files that are created.
- Repeat the assessment for every approved cloud environment.
Keep the client version, settings, and result for each data path. A working build confirms that the project can run. It doesn’t prove regional processing or a safe connector.
If a tool crosses the intended boundary, disable that route and correct the underlying permissions. Repeat the relevant test before handling actual client data.
Your company AI policy can tie these findings to approved projects. Set up one sanitized test repository using the intended account and record its results.
