How to use OpenAI Codex for sales, outbound and GTM work

What a GTM team hands to Codex

Codex is a coding agent, but the loop it runs (read context, run a command, check the result, try again) is the same loop a BDR runs all day. What it lacks out of the box is the GTM side: a place where accounts, leads, sequences, replies and pipeline live, with rules about what costs money and what reaches a prospect. OXYGEN is that place. Codex types the commands; OXYGEN holds the data, runs the sends and keeps the bill.

A typical week of work you can hand over looks like this. Most of it is reading and drafting, and the parts that spend credits or contact a person stop for your yes.

• Account research: an AI research column that researches each company and cites its sources, plus hiring, funding, news and tech-stack searches on credits.
• List building and enrichment: people and company search previews, then email and phone waterfalls across 17 and 13 providers, charged only on a hit.
• Sequences: email, LinkedIn and WhatsApp steps in one sequence, up to 26 versions of a step, and a stop when a lead replies on any channel.
• LinkedIn steps: visits, invites, messages, InMail, follows, likes and comments, run in the cloud from a connected account.
• CRM updates: companies, people and deals in the built-in CRM, with two-way HubSpot sync.
• Reply handling: one inbox with AI triage and drafted answers, and replies filed on the lead's record.

How Codex connects to outside tools: config.toml, set up once

Codex keeps its MCP servers in config.toml, by default ~/.codex/config.toml, with an optional .codex/config.toml inside a trusted project. Each server is a [mcp_servers.<name>] table: a command for a local server, or a url for a hosted one. OpenAI documents that the Codex CLI, the IDE extension and Codex in the ChatGPT desktop app share this configuration on the same machine, so you connect OXYGEN once and switch between them.

For a hosted server, codex mcp add <name> --url <address> writes the entry and codex mcp login <name> runs the OAuth sign-in. Inside the terminal UI, /mcp shows which servers are live. Per server you can also allow or deny single tools and set how Codex asks before calling them, which matters for a GTM workspace and is covered below.

Sources: OpenAI: Model Context Protocol in Codex

CLI or MCP from Codex: which path for which job

The OXYGEN CLI is the primary path in Codex. It carries the full command surface, returns one JSON envelope with a web_url on every state-bearing command, and exits with a code Codex can branch on: exit 7 means an approval or spend gate stopped the command and nothing was spent. The hosted MCP server is optional. Codex has no tool search, so connect it on the core profile (?toolset=core), which lists a bounded set of tools plus a capability search; every other tool stays callable by exact name.

One Codex detail changes the CLI path. In the default workspace-write sandbox, OpenAI turns network access off for the commands Codex runs, and every oxygen command talks to oxygen-agent.com. Codex will either ask you to approve each call or you allow network in config.toml. MCP connections sit outside that command sandbox, so the MCP path works with network still off. Use the CLI for bulk work and file imports, and MCP when you would rather not open the shell to the network.

Sources: OpenAI: Codex agent approvals and security

Two approval layers: Codex's sandbox and OXYGEN's spend gate

Codex has its own controls. The sandbox mode (read-only, workspace-write or danger-full-access) decides what a command can touch, and the approval policy (on-request or never) decides when Codex stops to ask. For MCP tools, default_tools_approval_mode takes auto, prompt, writes or approve; writes makes Codex prompt for any tool not marked read-only, and OpenAI notes that Codex asks before a tool that declares itself destructive. OXYGEN's tools declare which ones only read.

Those controls govern Codex. They do not know what a lead costs or whether a message reaches a buyer. OXYGEN's gate does: previews and dry runs are free, while a paid provider call, an enrichment run, a sequence launch, a LinkedIn action or a CRM sync refuses to run without an explicit approval, and anything with a price also needs a credit ceiling. Run Codex on on-request with writes for the OXYGEN server, and you see both the tool call and the scope before anything spends or sends. Skip --yolo for prospecting work.

Sources: OpenAI: Model Context Protocol in Codex, OpenAI: Codex agent approvals and security

Teach Codex your outbound rules with AGENTS.md and skills

Codex reads AGENTS.md before it starts work: a global file in ~/.codex, then one per directory from the project root down, with closer files winning. That is the place for GTM rules you never want to repeat in a prompt. Keep a small folder for outbound work and put your rules in its AGENTS.md.

Skills are the other half. A Codex skill is a folder with a SKILL.md that Codex loads when a task matches its description, or when you type $ and name it. oxygen skills install --agents codex installs one OXYGEN skill per feature (tables, enrichment, sourcing, the sequencer) plus onboarding, so Codex learns the right commands without loading the whole manual.

• Always preview or dry-run first, and show me the credit estimate.
• Never pass --approved until I say yes in this chat, and keep --max-credits at 50 unless I raise it.
• Read workspace context (ICP, personas, voice) before writing copy.
• Import CSVs with oxygen tables import, never by pasting rows into a prompt.

Sources: OpenAI: Custom instructions with AGENTS.md, OpenAI: Build skills for ChatGPT and Codex

The DIY route: Codex plus Apollo, lemlist, Instantly and Clay servers

A fair objection: why not connect the tools you already pay for? You can. Apollo offers a first-party plug-in for coding tools such as Codex and a standalone MCP server. lemlist documents codex mcp add lemlist with its hosted URL. Instantly hosts a server that exposes every V2 API endpoint as a tool. Clay's MCP brings its data providers, research agents and your team's workflows into ChatGPT, Claude and Codex. If your team lives in one of these tools, its own server is the shortest path, and Codex will drive it well.

The cost shows up when the job spans tools. Codex then holds the glue: matching people across Apollo and lemlist, stopping a LinkedIn step when an email reply lands, writing the outcome back to the CRM, and adding up credits from four vendors that each confirm actions in their own way. Someone on the team maintains that in AGENTS.md files and scripts. OXYGEN puts lead data, tables, sequences across email, LinkedIn and WhatsApp, the inbox and the CRM in one workspace with one approval rule and one credit balance. It also pushes leads into lemlist and Instantly campaigns if you keep them.

Sources: Apollo: Apollo MCP documentation, lemlist: Set up the lemlist MCP server in your LLM client, Instantly: MCP introduction, Clay: Clay MCP guide

What OXYGEN does not do here

• No contact database of its own: lead data comes from providers on credits, or from Apollo's database on your own Apollo key.
• No Salesforce sync. HubSpot syncs both ways and Attio one way.
• No inline widgets in Codex: open the web_url in each result to see a table or run.
• No SMS steps, and calls in a sequence are still in beta.
• It does not make LinkedIn automation risk-free: connected accounts can still be restricted by LinkedIn.