← Blog

OpenAI Codex CLI Gets Live Data With One TOML Block

Codex is great at code. It can't see SEC filings, FDA approvals, FRED data, or federal contracts — until you point it at Pipeworx. One line in config.toml gives it 3,000+ live-data tools across 660 sources.

OpenAI’s Codex CLI is a lightweight coding agent that runs in your terminal. It’s fast, it’s local, and it’s very good at the things a coding agent should be good at: reading files, running shells, editing repos. What it’s not built to know is anything outside your machine — the latest 10-K, the FAERS adverse-event count for a drug you’re integrating, the EPA emissions profile of a facility you’re modeling, who else has filed patents in the space you’re shipping into.

For the kind of work where that data matters, Codex needs an MCP server. Pipeworx is one — 3,000+ live-data tools across 660 verified sources behind a single endpoint, with a natural-language router on top so your agent doesn’t have to memorize pack names.

This post is the 30-second install.

Install (TOML)

Codex reads MCP servers from ~/.codex/config.toml. Add this block:

[mcp_servers.pipeworx]
url = "https://gateway.pipeworx.io/mcp"

Run codex and you have Pipeworx loaded. There’s no separate package to install, no API key required for the free tier (100 calls/day per IP), no per-source authentication. Streamable HTTP, Codex’s native transport.

Install (CLI, even faster)

If you have node, the Pipeworx CLI will write that TOML block for you:

npx pipeworx use ask-pipeworx --for codex

Idempotent — it’ll replace an existing [mcp_servers.pipeworx] section if one’s already there, preserve any other servers you’ve configured, and create the file if it doesn’t exist.

One pre-flight: sign in first

Codex won’t load any MCP server until OpenAI auth succeeds. Run codex login (uses your ChatGPT plan) or set an API key before you start. Otherwise codex exec hits a 401 at OpenAI’s WebSocket before it ever reaches our gateway, and you’ll think the install didn’t work. We hit this exact wall while dogfooding the post — it’s not our bug, it’s Codex’s startup ordering, but worth knowing.

Try it

Once it’s loaded, Codex sees a small set of meta-tools — ask_pipeworx, discover_tools, entity_profile, a handful of others. Those are routes into the 3,000-tool catalog, not the catalog itself. You don’t need to know any pack names. Ask things like:

What’s Apple’s latest 10-K filing? Pull the revenue line.

→ ask_pipeworx routes to SEC EDGAR, fetches aapl-20240928_htm.xml, returns the XBRL revenue concept with a pipeworx:// citation URI you can link.

Are there any FAERS adverse-event reports for tirzepatide in the last quarter?

→ Routes to FDA FAERS, returns ranked event types + counts.

What federal contracts has Palantir won this quarter?

→ Routes to our USAspending mirror (we proxy because USAspending.gov blanket-blocks Cloudflare Workers; sub-second now).

Find recent CVEs affecting libxml2.

→ Routes to CISA KEV + NIST NVD.

Show me overdue Phase 3 readouts at Moderna.

→ Routes to pharma_pipeline_catalysts — biotech catalyst calendar surfacing trials that finished but never published.

Codex’s strength is that it can take any of those answers and immediately do something useful with them in your repo — generate the migration, scaffold the integration test, write the changelog entry. The agent loop is local code, the data layer is live, and the integration cost on your side was three lines of TOML.

Why this matters more for Codex than for a chat agent

Browser-based coding assistants like ChatGPT or Claude.ai already have a web-search escape hatch built into the interface. When the model doesn’t know something, it can hand the question off to a search backend and synthesize a prose answer.

Codex CLI doesn’t have that. By design — it’s a local agent. The model has its training cutoff and the contents of your terminal. Anything outside that surface, it can’t reach unless you give it the reach. MCP is the mechanism, but you still need a server that does something useful. Generic MCP server lists are full of stdio wrappers around single APIs; you’d need to install dozens to cover what a single ask_pipeworx call covers.

The other angle: every MCP tool definition lives in your context window. Mounting twenty individual MCP servers — one per data source — burns tens of thousands of tokens of tool definitions before the agent does anything, and tool-selection accuracy drops sharply past ~50 visible tools. Pipeworx exposes ~17 meta-tools to Codex; the routing happens on our side at call time, not in the agent’s context.

Higher rate limits

Anonymous tier (no auth) is 100 calls/day per IP. If Codex is your daily driver, that’s tight. The cleanest path: sign in via GitHub OAuth at pipeworx.io/signup for 2,000/day on a stable account identifier (doesn’t rotate with your IP). BYO-key tier (500/day) works too — pass X-API-Key via Codex’s http_headers config:

[mcp_servers.pipeworx]
url = "https://gateway.pipeworx.io/mcp"
http_headers = { "X-API-Key" = "your-key" }

Or bearer_token_env_var = "PIPEWORX_TOKEN" if you’d rather source it from the environment.

Closing

If you build with Codex CLI, the install above turns it into a coding agent that also knows what the SEC, FDA, FRED, USPTO, Census, EPA, and 654 other sources are saying right now. Three lines of TOML, no per-source setup, no stale training data.

We watch our own gateway logs and we can see Codex hitting us — across multiple alpha versions, multiple IPs, growing weekly. If you’re on the Codex team and want a managed key for unthrottled testing, email me.