Codex is OpenAI’s coding agent. The codex CLI reads a real repository, runs commands, and calls tools from MCP servers you register with codex mcp add. Pipelock covers two of those paths. It wraps each MCP server with pipelock mcp proxy, and it inspects outbound requests from commands that honor proxy settings.
This page is about the Codex CLI at runtime. OpenAI’s separate Codex Security product scans connected GitHub repositories, and OpenAI’s own security page points readers looking for it elsewhere. The full command reference for this integration lives in the Codex integration guide on GitHub.
What Codex already enforces
Codex ships real controls, and they’re worth knowing before adding anything. On its approvals and security page (read 2026-10-28), OpenAI says:
- “By default, the agent runs with network access turned off.”
- Locally, Codex “uses an OS-enforced sandbox that limits what it can touch (typically to the current workspace), plus an approval policy that controls when it must stop and ask you before acting.”
- Codex’s automatic approval reviewer “checks for data exfiltration, credential probing, persistent security weakening, and destructive actions.”
When you turn on network access for sandboxed commands, Codex offers an optional network proxy with domain rules. Its configuration reference (read 2026-10-28) lists features.network_proxy as “experimental; off by default” and says it “Does not filter web search, apps, MCP, or other hosted tools.” The same page says “App and connector traffic is not controlled by the sandboxed-command network proxy or its domain allowlist.”
What Pipelock adds
Codex’s controls decide where a command may go and when you get asked. Pipelock looks at what the traffic carries, on the paths you route through it.
| Path | What Pipelock checks | How it’s wired |
|---|---|---|
| Codex to an MCP server | Tool call arguments for secrets, credentials and injection patterns | pipelock codex install, or a manual codex mcp add wrap |
| MCP server back to Codex | Tool results for prompt injection, using six normalization passes | Same wrapper |
Tool discovery (tools/list) | Poisoned descriptions, schema injection, and definitions that change mid-session | Same wrapper |
| Proxy-aware commands (curl, package managers, scripts) | Destination policy on HTTPS; DLP, SSRF and URL exfiltration checks, plus injection in responses, on plain HTTP or with TLS interception on | pipelock run with HTTPS_PROXY set |
| Hosted tools, web search, apps | Not covered | These don’t pass through a local MCP wrapper or proxy |
A sandboxed agent can still carry a credential through a connection it’s allowed to make. That’s the case content inspection exists for. See MCP tool poisoning for what discovery scanning catches.
Set it up
1. Install Pipelock and generate a config
# Requires Go 1.26+, Git, and Make. Start in a directory without a pipelock subdirectory. Community build only; use a release binary for paid features.
git clone --branch v3.7.1 --depth 1 https://github.com/pipelab-org/pipelock.git
make -C pipelock install
# Homebrew alternative on macOS/Linux: brew install luckyPipewrench/tap/pipelock
pipelock generate config --preset balanced -o "$PWD/pipelock.yaml"
balanced isn’t a warn-only mode on the MCP path. When pipelock mcp proxy starts with it, the wrapper logs response=block, input=block, tools=warn and policy=warn for an untrusted server. Secrets in tool arguments and injection in tool results are blocked from the first call, while tool-description findings and tool policy are logged as warnings. pipelock generate config --list shows every preset.
2. Wrap the registered MCP servers
pipelock codex install --config "$PWD/pipelock.yaml" --dry-run
pipelock codex install --config "$PWD/pipelock.yaml"
The installer reads the servers that codex mcp list reports and rewrites each one it can preserve to launch through pipelock mcp proxy. It embeds the absolute config path, so the wrapped servers don’t depend on the directory Codex starts in. It skips servers that are already wrapped, so you can run it again after codex mcp add registers a new one. A server registered by URL becomes a stdio wrapper that reaches the original address through --upstream.
It also skips any server whose settings codex mcp add can’t carry over: a disabled server, custom timeouts, a custom working directory, env_vars passthrough, an environment key it can’t pass safely, or a URL server with auth or header settings. The dry run prints skip <name> (<reason>) for each one and ends with a Plan: line counting the servers it wraps and skips. The install still succeeds when it skips servers, and every skipped server keeps talking to Codex without Pipelock in between. Wrap those by hand (step 3) once you’ve moved the setting the installer can’t keep, or accept that they’re unprotected.
Restart Codex, then check:
codex mcp list
Confirm that each server’s command is pipelock. Then prove the wrapper is in the path: call one tool per server with a synthetic test credential in an argument, such as the example access key AWS publishes in its documentation. A wrapped server answers with pipelock: request blocked by MCP input scanning instead of running the call. A successful call means that server isn’t wrapped, because an ordinary tool call works the same with or without Pipelock.
3. Or wrap one server by hand
codex mcp add filesystem \
-- pipelock mcp proxy --config "$PWD/pipelock.yaml" \
-- npx -y @modelcontextprotocol/server-filesystem ~/projects
Codex stores MCP servers in ~/.codex/config.toml, or in a trusted project’s .codex/config.toml. A wrapped entry looks like this:
[mcp_servers.filesystem]
command = "pipelock"
args = [
"mcp", "proxy",
"--config", "/home/you/pipelock.yaml",
"--",
"npx", "-y", "@modelcontextprotocol/server-filesystem", "/home/you/projects"
]
4. Route proxy-aware commands through Pipelock
The balanced and strict presets ship with the forward proxy off, and pipelock run refuses CONNECT requests until you turn it on. Edit the config first:
forward_proxy:
enabled: true
Then start the proxy and point commands at it:
pipelock run --config "$PWD/pipelock.yaml" &
export HTTPS_PROXY=http://127.0.0.1:8888
export HTTP_PROXY=http://127.0.0.1:8888
export NO_PROXY=127.0.0.1,localhost
This only reaches commands that honor proxy variables, and only matters once you’ve given sandboxed commands network access. A tool that ignores HTTPS_PROXY or opens a raw socket goes around it. Use pipelock contain or another network boundary when you need that path closed.
Plain HTTPS through the proxy shows Pipelock the destination host, not the request body. Turn on TLS interception when you need headers and bodies scanned. See known limitations for the CONNECT tunnel limit.
Pass credentials to MCP servers
Codex’s codex mcp add --env sets the wrapper’s environment. Pipelock doesn’t forward every wrapper variable to the MCP server it launches. Pass the ones a server needs with Pipelock’s own --env:
codex mcp add my-server \
-- pipelock mcp proxy --config "$PWD/pipelock.yaml" --env API_KEY \
-- my-mcp-server
Pipelock refuses to pass code-loading variables and other blocked names into the server at startup.
Undo it
pipelock codex remove --dry-run
pipelock codex remove
remove restores only the servers Pipelock wrapped. Registrations it doesn’t recognize as Pipelock wrappers stay as they are.
Check your controls
pipelock check --config "$PWD/pipelock.yaml"
pipelock verify-install --config "$PWD/pipelock.yaml"
check validates the config. verify-install runs synthetic scanner checks against it with a temporary proxy, so a pass shows the scanner works with that config. It reads the file as written. A generated preset leaves the MCP scanning sections unset, and pipelock mcp proxy turns them on when it starts, so verify-install reports those checks as failed until you enable them in the file. Neither command proves Codex is using your running proxy or your wrapped servers. The blocked synthetic-credential call in step 2 shows an MCP server is wrapped. It says nothing about the forward proxy. For that, run a proxy-aware command from a Codex session and confirm the request appears in Pipelock’s log.
Honest limits
- Routed paths only. Pipelock sees MCP servers you wrapped and commands that use the proxy. Servers the installer skipped, hosted tools, web search and apps don’t pass through either.
- Pattern-based detection. Injection and poisoning checks match known patterns after normalization. A novel phrasing can pass.
- No proxy, no coverage. A command that skips the proxy is outside Pipelock’s view unless containment forces the path.
The full register is on known limitations.
Where to go next
- MCP proxy: how the wrapper scans both directions
- MCP tool poisoning: what discovery scanning and drift detection catch
- Grok Build security: the same manual MCP wrap for a client without an installer
- Claude Code security: hooks, egress inspection and containment for Claude Code
- Pipelock contain: close the direct-egress path on Linux
Sources read 2026-10-28: OpenAI’s Codex security page, approvals and security page, configuration reference and MCP page, and the Pipelock v3.7.1 Codex guide. OpenAI changes these pages; check them before relying on a quoted default.