The Codex CLI is OpenAI's coding agent for the terminal. It reads the files in a folder, runs commands and edits them, and it follows the instructions in an AGENTS.md file.
The ElasticFunnels CLI turns your brand into that folder and writes the AGENTS.md. Codex can then create pages, publish drafts, set up split tests and read your stats with the same ef commands you would type.
When you pick an agent for funnel work, I'd look past the model at first. What decides whether it's useful is access to your pages as files, and to the same commands you would run. Once it has that, Codex and Claude Code do this job in much the same way, and the difference comes down to setup. For Codex, that setup has one trap, and it's covered in step 2.
What you need
- The Codex CLI (
npm i -g @openai/codex, or the installer in OpenAI's Codex docs), signed in with your ChatGPT account. - An ElasticFunnels brand. The CLI is included on every plan.
- Node.js 18 or newer and the ElasticFunnels CLI:
npm i -g @elasticfunnels/cli.
Step 1: bind a folder and write AGENTS.md
mkdir my-brand && cd my-brand ef init
ef init signs in through the browser, pulls your pages and writes three guidance files: CLAUDE.md, a Cursor rule, and AGENTS.md for Codex. They carry the same rules: pull before editing, never touch a file's first line, lint before pushing, and how split tests and stats work. If the folder already exists, ef codex writes just the AGENTS.md, and is safe to re-run after a CLI update.
Read that file once yourself. It's short, and it's the difference between an agent that knows it must never touch a page's first line and one that finds out when the push is refused.
Step 2: let ef reach the network
This is where most first runs stall. Codex runs commands in a sandbox, and its default mode, workspace-write, blocks network access. Every ef command that talks to your brand needs it: pull, push, stats.
Two ways through:
- Approve per command. Codex asks before running a command that needs the network. Fine for a first session.
- Allow network in the workspace sandbox. Start Codex with the setting on:
codex -c sandbox_workspace_write.network_access=true
or set it once in ~/.codex/config.toml:
[sandbox_workspace_write] network_access = true
File writes stay limited to the project folder either way. Your ElasticFunnels key lives in that folder's .ef/auth, so ef works without you pasting anything into the chat.
Step 3: brief Codex on the page
Run codex in the folder and describe the page you want. Be specific about the angle and the structure, and ask for a draft:
Create a presell page at offers/sleep-presell. Angle: a reader who wakes at 3 a.m. every night. Sections: hook, the real cause, what changed for one reader, a short proof block, and a button to /offers/sleep. Match the styling of pages/offers/sleep.ef. Lint it, push it as a draft and give me the preview link.
What Codex runs
These are the ef commands the brief turns into. Each one's behaviour is checked against the CLI's help for version 0.18.0:
ef pull pages/offers/sleep.ef # read the page to match, fresh from the server ef pages create offers/sleep-presell # create the page and pull the empty file # ...Codex writes pages/offers/sleep-presell.ef... ef lint pages/offers/sleep-presell.ef # catch template errors before they go up ef push pages/offers/sleep-presell.ef --draft ef preview offers/sleep-presell # preview link for you to open
What the agent did: it read an existing page for the styling, created the new one on the server, wrote it, checked it and saved the content as a draft instead of publishing it. The preview link opens the draft. When you are happy, ef pages publish offers/sleep-presell puts it live. Of everything above, --draft is the one flag I'd never let an agent drop, even on a page no ad points to yet.
If you or a teammate changed the page in the app while Codex worked, the push is refused with exit code 4 and nothing is overwritten. Codex can then run ef diff --server on the file to see the difference, and ef pull --merge to merge it.
Step 4: test it and read the numbers
A new presell is a guess until it has traffic, however good it looks in the preview. Put it in a same-URL split test against the page your ads already use; the Claude Code walkthrough shows the exact commands, and they are the same for Codex. Then ask Codex to read the result:
ef stats splits ef stats split <id> --range 30d --tz America/New_York
For a repeatable report, codex exec runs a task without the interactive session:
codex exec "Run ef stats --range 7d --tz America/New_York and ef stats splits. Summarise revenue, conversion rate and every running test in five bullets. Quote the app's split-test significance results; don't compute your own or pick a winner."
How to read a split-test result, and how to turn it into the next test, is in AI A/B testing with your funnel stats.
What Codex can't do here
- Run your ads. The CLI has no ad-platform commands. It builds and tests the pages the ads point to.
- Connect gateways, networks or ad accounts. That happens in the ElasticFunnels app.
- Create DNS records.
ef domains addadds a domain andef domains recordsprints what to set, but you set them at your registrar.
No terminal at all? The in-app AI page builder writes presells and advertorials from a description. Every agent option is on the AI marketing agents page.
- I wouldn't switch on network access in the sandbox on day one. Approving each command for a session teaches you what the agent actually does.
- Never solve the sandbox by switching to full access. You only need the network, and file writes should stay inside the project.
- A vague brief gets you a generic page. Name the angle and the page to match, or don't be surprised by the result.
- A presell that looks great in preview has proved nothing. It earns its place in a split test.
The sandbox setting is the only part of this that feels fiddly, and it exists for a good reason. Once it's sorted, Codex turns a paragraph of brief into a draft page with a preview link in one session. After that, the only question left is whether the page is worth testing.
