Does OFM modify my ~/.codex/config.toml?

No. Every setting OFM applies is passed as a -c key=value override on the command line for that session only, and secrets travel through the session environment rather than a file.

Why does an HTTP MCP server need experimental_use_rmcp_client?

Without that flag Codex ignores HTTP MCP transports silently — no error, no tools. OFM adds it automatically whenever you declare a non-stdio server.

Codex

How Open Free Max runs the OpenAI Codex CLI — resume by id, sandbox and approval policy, and MCP servers injected as command-line overrides that never touch your config.toml.

Codex is the second most deeply integrated CLI in Open Free Max. Everything OFM configures is passed as command-line overrides, so your own Codex configuration stays untouched.

What OFM does with it

Resume. Codex cannot be given a session id at startup, but it can reopen one afterwards. OFM runs codex resume <id> when it knows the id, and codex resume --last otherwise.
MCP servers as overrides. Declared MCP servers and a connected Obsidian vault are translated into -c mcp_servers.<name>.… overrides. Nothing is written to ~/.codex/config.toml.
History ingestion. Codex transcripts feed project memory.
Estimated accounting. Codex does not publish per-turn token counts the way Claude Code does, so the Consumption view marks its numbers estimated.

Launch flags

Setting	Effect
Model	e.g. `gpt-5-codex`, `o4-mini`. Empty = config default
Approval policy	`untrusted` (asks except for safe reads), `on-request`, `never`
Sandbox	`read-only`, `workspace-write`, `danger-full-access`
Full-auto	Low-friction preset = `on-request` + `workspace-write`
Bypass approvals + sandbox	Disables both safeguards; exclusive with the two settings above
Web search	Enables live web search
Config profile	Applies a named profile from `config.toml`
Local provider (OSS/Ollama)	Uses the local open-source provider
Additional folders	Extra writable directories
Config overrides	Raw TOML `key=value`, one per line (e.g. `model_reasoning_effort=high`)

Approval policy vs sandbox

These are two different safeguards and it is worth keeping them straight:

Approval policy decides when Codex asks you. It is what Mission Control sees and can answer for you.
Sandbox decides what the process is physically allowed to do at the OS level, whether or not anyone approved it.

The safe combination for unattended work is on-request + workspace-write: the agent stays inside the project folder, and anything that needs to leave it becomes a question Mission Control can route to you. Choosing “Bypass approvals + sandbox” removes both layers at once and makes the other two settings inert.

MCP transport details

OFM handles two shapes:

stdio servers — command, args and env are passed as overrides; environment variables are injected into the session process, which the server inherits when Codex spawns it.
HTTP servers — url, a 20-second startup timeout, and experimental_use_rmcp_client=true. The bearer token is never put on the command line: OFM passes bearer_token_env_var and sets that variable in the session environment, so the secret never appears in a process listing.

Installation

codex is a native binary — no Node.js required. Under WSL, install it inside the distribution.

Frequently asked

Does OFM modify my ~/.codex/config.toml?: No. Every setting OFM applies is passed as a -c key=value override on the command line for that session only, and secrets travel through the session environment rather than a file.
Why does an HTTP MCP server need experimental_use_rmcp_client?: Without that flag Codex ignores HTTP MCP transports silently — no error, no tools. OFM adds it automatically whenever you declare a non-stdio server.