Codex CLI

MCP setup

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

[mcp_servers.chime]
command = "chime"
args = ["mcp", "serve"]

[mcp_servers.chime.env]
CHIME_HOME = "~/.chime-codex"

or add it with Codex’s own CLI:

codex mcp add chime --env CHIME_HOME=~/.chime-codex -- chime mcp serve

The optional CHIME_HOME override keeps Codex’s session state in its own directory, separate from any other harness you also run Chime with.

Known gotcha: Codex’s MCP allowlist matches on both server name and identity, and MCP servers in config.toml have been reported not picked up after some updates. After editing, verify the server registered with codex mcp or /mcp before assuming it’s live.

Instructions

Codex reads AGENTS.md for project instructions rather than a dedicated skill-file slot. If you want Codex to pick up Chime’s agent runbook automatically, add a reference to it (or the relevant excerpt) in your project’s AGENTS.md.

Keeping the alias aligned

chime_notify and whatever’s listening for the reply need to agree on one alias, or the reply lands somewhere nobody’s watching. Codex has a SessionStart hook, so you can mint CHIME_ALIAS there for the whole session, the same way Claude Code does. If you don’t wire that up, Chime falls back to a persisted alias at $CHIME_HOME/session-alias — as long as the MCP server and any chime CLI calls share one CHIME_HOME, they converge on the same alias with no hook required.

Listening for replies

Codex has no Monitor-equivalent for streaming a live command into agent turns, so use the portable MCP pattern instead — see MCP:

chime_wait — block until the next reply arrives (or a timeout), for when you need the human’s answer before continuing.
chime_receive — a non-blocking drain, for polling between work steps.

The chime CLI works the same way from a shell if MCP isn’t wired up in a given session — see CLI.

MCP — full tool reference.
Integrations — every harness and its status.