Codex

Codex is OpenAI's agentic coding CLI. As a Subshell harness it runs the interactive TUI in a pane, with the subshell MCP server wired into every launch, without ever touching the ~/.codex directory that holds your Codex sign-in and configuration.

Finding the binary

Subshell resolves codex on the machine that will run the pane: the codex on the PATH there (including what a login shell would find), then its known install locations under your home directory, the npm and bun global bins among them. Set CODEX_PATH on that machine's environment to name the binary explicitly. If detection finds nothing, Installing Agent CLIs covers the one-line installer, and the vendor CLI docs the manual path.

What a launch looks like

A bare Codex launch opens the interactive TUI, so that is what a subshell runs. Settings arrive as per-invocation flags: the preset editor offers model (-m), sandbox (-s: read-only, workspace-write, or danger-full-access; the editor labels the third one "Full access"), and approval behaviour (-a), and any preset or one-off flags ride along after them.

Two deliberate absences:

• Your sign-in is used as-is. Subshell never redirects CODEX_HOME: that directory holds your auth.json and config.toml, and pointing it elsewhere would log the subshell out of ChatGPT and hide your own configuration.
• Nothing dangerous is baked in. A launch never carries an approval-and-sandbox bypass; if you want one, putting it in your own preset flags is your call, not a default Subshell makes for you.

Cross-subshell tools, automatically

The subshell MCP server (channels, sibling inspection, coordination) is registered for every Codex subshell automatically, in the dialect Codex itself prefers: each launch carries its registration as per-invocation config overrides (-c mcp_servers.subshell.…), which Codex merges over your ~/.codex/config.toml for that run only. There is no per-subshell config file Codex has to read, and your own config is never modified.

The override names only the command to spawn. The subshell mcp child inherits the credential baked into its pane's environment, each subshell's own scoped API key, so the same one-line registration is correct for every subshell on a shared machine. On a node, the launch carries the registration to that machine and points it at the subshell binary installed there; nothing on the node needs configuring.

If you also want the plain codex you run in your own terminal to reach Subshell's tools, add an [mcp_servers.subshell] block with the command and args of subshell mcp to ~/.codex/config.toml yourself; Subshell's automatic wiring is deliberately scoped to the panes it launches.

Restarts start fresh

Codex has no way to name or pin a conversation at creation, so Subshell does not forward the subshell's display name and cannot resume a conversation across a restart: an auto-restart or a manual one opens a fresh Codex session. Claude Code is the one built-in with restart-resume.

See also

• OpenCode: the same automatic wiring, done through a merged config layer
• Presets: saved per-harness configuration, including Codex's settings fields
• The MCP server: what the registered tools actually give the agent
• Installing Agent CLIs: the in-page installer for the codex binary

Edit on GitHub