You're on Codex: give it governed data context and approved data changes
Your engineers already work in Codex. Connect Data Workers over MCP in config.toml and Codex answers from governed data context, while every data change goes through approvals and receipts.
Your engineers already live in Codex. They run codex in the terminal, open the Codex sidebar in VS Code or Cursor, and hand longer work to Codex Cloud, where each task gets its own workspace and comes back as a diff or a pull request. Your admins have set the sandbox mode and approval policy, and they control which MCP servers people can enable from requirements.toml. Codex is good at the job it was built for: reading a repository, writing the change, running it in a sandbox and asking before it steps outside. Data Workers is the agentic data platform that sits behind it. Connected over MCP, Codex answers from your governed data context, and every change to production data goes through Data Workers' approvals and leaves a receipt.
Key takeaways
- •Codex is the coding agent. Data Workers is the data team it calls. Codex writes and runs the code; Data Workers brings the context, owns the change in production and proves it worked.
- •One config file reaches every local Codex surface. The Codex CLI, the IDE extension and the ChatGPT desktop app share one
config.toml, so the Data Workers[mcp_servers]entries connect all three. - •Two locks on every write. Codex asks before the tool calls you mark for approval; Data Workers applies its per-domain guardrail, keeps a rollback point and writes the receipt.
- •Climb the ladder one domain at a time. Start read-only (L1), move to propose (L2), then act reversibly (L3), and let trusted domains run autonomously (L4).
- •Nothing to migrate. Codex, your repositories, Snowflake, dbt, Airflow and Tableau all stay. Data Workers works through each system's own API.
Codex is the coding agent. Data Workers is the data team it calls.
Codex reads your dbt project, your Airflow DAGs and your SQL, and writes the change you ask for. What it doesn't hold is the state of the estate: which table is canonical, who owns it, what reads it downstream, what changed overnight, and who must approve a fix to finance data. That is what Data Workers holds. The Data Context Wizard keeps one governed context graph across warehouses, dbt, orchestration and BI. The Data-Agents Swarm (20+ specialist agents) does the data work. The Autonomous Data-Conductor runs each fix end to end: detect, diagnose, fix, review, verify, remember. Spellbook Data Catalog (in preview) is where people review, approve, roll back and audit.
Here is one request, end to end. It is an illustration, not a customer case.
| Time | System | What happens |
|---|---|---|
| 06:40 | Airflow | The load_billing DAG times out and a task retry reloads the invoices batch |
| 06:52 | Snowflake | raw.invoices now holds 41,880 duplicate rows |
| 07:30 | dbt | The run succeeds; fct_mrr sums the duplicates |
| 09:05 | Tableau | The MRR workbook shows a jump nobody can explain |
| 09:12 | Codex (IDE extension) | An analytics engineer asks: "Why did MRR jump overnight?" |
| 09:13 | Codex | Codex calls Data Workers over MCP (diagnose_incident, blast_radius_analysis) |
| 09:14 | Data Workers | Traces the jump to the retry; blast radius is 3 dbt models and 2 Tableau workbooks |
| 09:16 | Codex | Codex asks to run remediate; the engineer approves the tool call |
| 09:31 | Spellbook | The finance data owner approves the change, as the finance domain requires |
| 09:33 | Snowflake | Data Workers removes the duplicates and keeps a rollback point |
| 09:47 | dbt | dbt rebuilds; row counts match the billing source; tests pass; receipt written |
| 10:00 | Tableau | The MRR tile is right before the exec review |
The engineer never left the editor. Codex did what it does best: took the question, called the right tools, showed the plan and asked for approval. Data Workers did the data work: it found the cause in Airflow, measured the blast radius through dbt into Tableau, routed the change to the person who owns finance data, made the fix reversibly and proved it with row counts and tests. Meanwhile Codex can write the lasting fix in the repository, a unique key on the incremental model, as a pull request your team reviews as usual.
| What Codex does | What Data Workers does |
|---|---|
| Takes the question in the terminal, the editor or the desktop app | Answers it from governed context: lineage, ownership, definitions, recent changes |
| Reads and edits the repository in an OS-enforced sandbox | Reads and changes Snowflake, dbt, Airflow and BI through each system's own API |
| Asks before tool calls you mark for approval | Applies per-domain guardrails and routes the change to the data owner |
| Writes the code fix and opens the pull request | Owns the production change, keeps a rollback point and verifies downstream |
| Shows the diff for this session | Writes a receipt that outlives the session: who, why, what changed, how to undo |
Why doesn't Codex just do this itself?
Focus and risk. OpenAI built Codex to work on code, and its design is right for that job. Locally it runs in an OS-enforced sandbox that limits writes to the active workspace, with network access off by default. Its approval policy decides when it must stop and ask. Admins enforce those settings and the list of allowed MCP servers through requirements.toml. Every one of those controls is about the session: what this agent, on this machine or in this cloud task, may touch.
Changing production data is a different product. A fix to raw.invoices touches systems Codex doesn't run, owned by people who aren't in the session, with downstream readers nobody in the repository can see. Doing it safely takes context about every other system, a blast radius, an approver per domain, a rollback plan, verification after the fact and a receipt an auditor can read next quarter. It also means carrying the liability for changes in tools OpenAI doesn't own. A general coding agent is right not to take that on. That is the product Data Workers is, and Codex is the best place for your engineers to ask for it.
Every tool owns a slice. Data Workers covers the whole lifecycle
Each point tool adds another console, another contract and another handoff. Data Workers covers the whole data lifecycle with one context, one approval flow and one audit trail. Codex owns a valuable slice of it: writing and running code. It leads where that is the work: pipeline code.
| Stage | Data Workers | Codex | Why we scored it this way |
|---|---|---|---|
| Catalog & Context | 9 | 4 | Codex reads the repository, AGENTS.md and the files you open; it doesn't keep a catalog. Data Workers keeps one governed context graph across warehouses, dbt, orchestration and BI. |
| Analytics & Insights | 8 | 5 | Codex explains code and query results in the session. Data Workers answers business questions from governed definitions, lineage and ownership. |
| Data Quality | 8 | 5 | Codex writes dbt tests and SQL checks when you ask. Data Workers writes, runs and repairs checks across platforms and keeps them running. |
| Observability & Incidents | 8.5 | 3 | Codex debugs the error in front of it; it doesn't watch production. Data Workers detects, traces and closes incidents across systems with a receipt. |
| Pipelines & Ingestion | 8.5 | 9 | Codex leads. It writes pipeline code, dbt models and DAGs, runs them in the sandbox, and hands back a diff or pull request. Data Workers owns the run in production behind approval. |
| Schema & Migration | 8 | 6 | Codex writes migrations and refactors well. Data Workers checks the blast radius across every downstream system before a schema change lands. |
| Governance & Access | 8.5 | 3 | Codex governs Codex: sandbox, approval policy and an admin MCP allowlist in requirements.toml. Data Workers proposes least-privilege grants on your data platforms behind approvals. |
| Security & Privacy | 8 | 5 | Codex runs in an OS-enforced sandbox with network off by default, and admins enforce requirements. Data Workers flags sensitive column names in pull request review across the estate. |
| Cost / FinOps | 8 | 2 | Codex doesn't work on your warehouse bill. Data Workers traces Snowflake credits to the dbt model behind them and drafts the fix for its owner. |
| MLOps & Models | 7.5 | 5 | Codex writes training, feature and evaluation code when you ask; its docs describe no model registry, serving or drift monitoring. Data Workers keeps the features and training data under every model healthy and traced. |
How Codex and Data Workers work together
Codex stays on top, where engineers ask, delegate and approve. Data Workers sits underneath as MCP servers: the Context Wizard, the Swarm, the Conductor and the guardrails. Spellbook is where people look: data owners review and approve changes, roll them back and read the audit trail.
Setup over MCP today. Every Data Workers agent is a standard MCP stdio server, and Codex starts it from ~/.codex/config.toml. Following the client setup docs, clone the repository and register the agents you need with one command each:
codex mcp add dw-incidents -- /path/to/dataworkers-claw-community/start-agent.sh dw-incidents
codex mcp add dw-context-catalog -- /path/to/dataworkers-claw-community/start-agent.sh dw-context-catalogThen set approvals per tool. The Codex CLI, the IDE extension and the ChatGPT desktop app read the same ~/.codex/config.toml, and a trusted project can carry its own .codex/config.toml. Example:
# Example: ~/.codex/config.toml (or .codex/config.toml in a trusted project)
[mcp_servers.dw-context-catalog]
command = "/path/to/dataworkers-claw-community/start-agent.sh"
args = ["dw-context-catalog"]
startup_timeout_sec = 20
default_tools_approval_mode = "prompt"
# Read-only context runs without a prompt
[mcp_servers.dw-context-catalog.tools.blast_radius_analysis]
approval_mode = "auto"
[mcp_servers.dw-incidents]
command = "/path/to/dataworkers-claw-community/start-agent.sh"
args = ["dw-incidents"]
startup_timeout_sec = 20
# Ask before every incident tool by default
default_tools_approval_mode = "prompt"
[mcp_servers.dw-incidents.tools.diagnose_incident]
approval_mode = "auto"
# Changes always ask in Codex, then pass Data Workers' own guardrail
[mcp_servers.dw-incidents.tools.remediate]
approval_mode = "prompt"For a shared Data Workers deployment, Codex also connects to Streamable HTTP servers by url, with a bearer token from an environment variable or OAuth through codex mcp login. Admins who allowlist MCP servers add matching entries to requirements.toml, by command for stdio or by URL for HTTP, and Codex enables a server only when both its name and identity match. Codex Cloud environments carry their own network and secrets settings, so roll out locally first and treat cloud tasks as their own step. The Data Workers on Codex CLI page covers the open-source agents on Codex, and Data Workers + Claude Code, Cursor and Codex covers the wiring across all three agents.
The same request on the autonomy ladder. Autonomy is set per domain, on the ladder L0 manual, L1 observe, L2 propose, L3 act reversibly, L4 autonomous.
- •L0 manual. The engineer queries Snowflake by hand and greps the dbt project. Codex helps with the SQL; nobody has the lineage.
- •L1 observe. Codex calls Data Workers and gets the cause, the blast radius and the owner. Nothing changes.
- •L2 propose. Data Workers drafts the fix with its blast radius and rollback plan. The finance owner approves in Spellbook; Codex asks the engineer before the tool call.
- •L3 act reversibly. For a domain you trust, Data Workers removes duplicate loads on its own with a rollback point and writes the receipt. The engineer reads it in Codex.
- •L4 autonomous. The Conductor catches the duplicate load at 06:52, before dbt runs, fixes it and verifies it. Codex is where an engineer reads the receipt the next morning.
Codex approvals and Data Workers guardrails stack. Turning one up never turns the other down.
What changes for your team
Engineers keep the agent they already use. What changes is the work behind it: the jobs that used to wait for a person with the right access and the right context now run through Data Workers, at the autonomy level each domain sets.
Data owners stop being pinged in Slack for "is this table right?" and start approving scoped changes in Spellbook. On-call stops starting from zero, because the first question typed into Codex already returns the cause and the blast radius. The platform team stops writing one-off scripts for each team's MCP setup: one shared config, one allowlist, one audit trail.
Keep Codex, or consolidate?
Keep Codex if you love it; Data Workers works with it from day one. Many teams consolidate once Data Workers runs that slice too. In practice, with a coding agent, keeping it is the usual answer: Codex is where your engineers write code, and Data Workers makes every data question and data change they send from it governed. The same Data Workers server also answers in Claude, Cursor and ChatGPT Enterprise, so teams that use more than one agent share one context and one audit trail. For the whole category, see Your company just rolled out AI assistants. Now what?.
The case for your CFO
You already pay for Codex seats, and engineers already use them on data work. The outcome to buy now is that the questions they ask get governed answers, and the changes they ask for get made safely: fewer wrong numbers reaching leadership, incidents closed in the same morning, and an audit trail for every change to production data.
The risk story is plain. At L1, Data Workers only reads and explains. At L2, it proposes and a named owner approves. At L3, it acts only where a change is reversible, and keeps the rollback point. L4 is reserved for domains you've trusted on evidence. Every action leaves a receipt: who asked, who approved, what changed, what it touched, and how to undo it. Codex keeps its own sandbox and approval prompts, so there are two locks on every write. Nothing migrates: Codex, Snowflake, dbt, Airflow and Tableau all stay. The cost case and how to model it are on the ROI page, and the deployment and data-handling answers are on the security page.
Why now: coding agents are already the front door for data work. Every week without governed context is another week of engineers guessing which table is canonical, and of production changes made with personal credentials and no receipt. The safety page walks through what agents can and can't do at each level, and the build-vs-buy page covers what it takes to wire this yourself.
The first win is small and visible: read-only Data Workers tools in Codex for one domain, so "why is this number wrong?" gets a traced answer. Start with a pilot; pricing has the details, and the pilot is credited in full against the first year.
The sentence to repeat upstairs: "Our engineers keep Codex; Data Workers gives it our governed data context and routes every data change through one approval flow with a receipt."
Getting started
Start with a pilot. Pick one domain where engineers already ask Codex about data, often finance or product analytics, add the Data Workers servers to config.toml with read tools on auto and change tools on prompt, and run it at L1 for the first weeks. Move that domain to L2 when the answers hold up, and to L3 for the fixes your team approves every time. See pricing; the pilot is credited in full against the first year.
FAQ
Does Data Workers bypass Codex's sandbox or approval prompts? No. Codex still decides when to ask, using the approval mode you set per server and per tool, and admin requirements still apply. Data Workers adds its own per-domain guardrail on top, so a change needs both.
Which Codex surfaces does this work in? The Codex CLI, the IDE extension (VS Code, Cursor, Windsurf) and the ChatGPT desktop app share one config.toml, so the same entries cover all three. Codex Cloud environments have their own network and secrets settings; roll out locally first, then configure cloud tasks as a separate step.
Can our admins control which MCP servers engineers use? Yes. Add the Data Workers servers to the mcp_servers approved list in requirements.toml, matched by command for stdio or by URL for Streamable HTTP. Codex enables a server only when its name and identity both match.
Won't more tools crowd Codex's context? Use enabled_tools and disabled_tools on each server entry to expose only the tools a team needs. Many teams start with the context and incident tools and add more as domains move up the ladder.
Whose credentials touch Snowflake? Data Workers' own credentials, scoped per domain, so no personal warehouse keys sit in a terminal. The engineer's identity is recorded on the receipt as the person who asked and approved.
We could wire a Snowflake MCP server into Codex ourselves. Why buy? You can connect a warehouse. The hard parts are the context across systems, the blast radius, the approvals by domain, the rollback and the receipts. The build-vs-buy page walks through it.
How is this different from the Claude Code vs Codex pages? Those help you choose an agent, for example Claude Code vs OpenAI Codex for data engineering. This page assumes you've chosen Codex and shows what to build on top of it.
Sources
- •OpenAI, Codex docs, "Model Context Protocol" (codex mcp add, config.toml keys, transports, default_tools_approval_mode and tools.<tool>.approval_mode, shared configuration across the ChatGPT desktop app, CLI and IDE extension): https://learn.chatgpt.com/docs/extend/mcp?surface=cli (checked Oct 2, 2026)
- •OpenAI, Codex docs, "Agent approvals & security" (sandbox, approval policy, network off by default, destructive MCP calls require approval): https://learn.chatgpt.com/docs/agent-approvals-security (checked Oct 2, 2026)
- •OpenAI, "Managed configuration" (requirements.toml, MCP server allowlist): https://learn.chatgpt.com/docs/enterprise/managed-configuration (checked Oct 2, 2026)
- •OpenAI, "Admin rollout guide" (Codex local and cloud workspace permissions, Codex Cloud off by default for Enterprise): https://learn.chatgpt.com/docs/enterprise/admin-setup (checked Oct 2, 2026)
- •OpenAI, "Codex CLI": https://learn.chatgpt.com/docs/codex/cli (checked Oct 2, 2026)
- •OpenAI, "Codex IDE extension": https://learn.chatgpt.com/docs/ide (checked Oct 2, 2026)
- •OpenAI, "Codex Cloud": https://learn.chatgpt.com/docs/cloud (checked Oct 2, 2026)
- •Data Workers, "Data Workers on Codex CLI": https://dataworkers.io/on/codex/ (checked Oct 2, 2026)
- •Data Workers, "Client Setup" (Codex CLI uses ~/.codex/config.toml; agents start as MCP stdio servers via start-agent.sh): https://dataworkers.io/opensource-docs/client-setup/ (checked Oct 2, 2026)
- •Data Workers open-source repository (tool definitions
diagnose_incidentandremediatein agents/dw-incidents,blast_radius_analysisin agents/dw-context-catalog; start-agent.sh): https://github.com/DataWorkersProject/dataworkers-claw-community (checked Oct 2, 2026)