Codex Says Code Mode Host Is Disabled? Restore Tool Access

If Codex starts normally but every shell, filesystem, GitHub, or documentation tool fails with Code Mode is unavailable because code-mode host is disabled, check the effective feature configuration before reinstalling anything. A fresh Codex CLI 0.147.0 report traced the failure to an existing [features] code_mode_host = false override.

The safest repair is to prove the override is responsible with a one-session enable flag, then remove only the stale false entry from the configuration layer that supplied it. Restart Codex and verify a read-only tool call. If the error changes to a missing codex-code-mode-host executable, stop: that is a separate packaging or executable-resolution problem.

Recognize This Exact Failure

This guide applies when all of these are true:

• Codex accepts prompts and can answer conversationally.

• Every tool-backed request fails before the requested command runs.

• The error says the code-mode host is disabled and Code Mode will fail closed.

• codex features list reports code_mode_host as false, or a reviewed config file explicitly sets it to false.

Record the evidence before changing configuration:

codex --version
codex features list | grep -E '^code_mode(_host|_only)?[[:space:]]'
codex doctor

Also preserve the exact error, operating system, architecture, installation method, and UTC time. Do not include tokens, private repository names, prompts, or complete configuration files in a public report.

The upstream reproduction was on macOS ARM64 after a Homebrew cask upgrade to Codex CLI 0.147.0. Treat that as the confirmed scope, not proof that every tool failure on every platform has the same cause.

Find the Explicit False Override

Codex reads user configuration from ~/.codex/config.toml and can also load project or profile layers. Check only the files relevant to the affected task:

rg -n '^[[:space:]]*code_mode(_host|_only)?[[:space:]]*=' \
  ~/.codex/config.toml .codex/config.toml 2>/dev/null

You are looking for this exact setting under [features]:

[features]
code_mode_host = false

Do not remove the whole [features] table. Other entries may be intentional. Do not paste the entire file into an issue or support chat because neighboring settings can contain private paths or endpoints.

If neither reviewed file contains the override but codex features list still reports false, check whether you launched Codex with --disable code_mode_host, a -c features.code_mode_host=false override, or a named profile. Diagnose the effective layer instead of editing random files.

Prove the Diagnosis With a One-Session Enable

Open a new Codex session from the same terminal, repository, and profile:

codex --enable code_mode_host

Inside that session, request one bounded read-only operation:

Run pwd and report its exact output. Do not change any files

If pwd runs, the temporary feature override confirms that the disabled host was blocking tool execution. Exit the session before making the persistent repair.

The one-session flag is useful because it changes only the current invocation. It does not rewrite configuration, delete state, or hide which setting caused the failure. OpenAI's configuration documentation defines codex --enable feature_name as the command-line equivalent of setting a feature to true.

Remove Only the Stale Setting

Open the configuration file that actually supplied code_mode_host = false. Back it up in a private location if your normal editor does not already keep history. Then choose one of these narrow repairs:

1. Remove only the code_mode_host = false line and let the current stable default apply.

2. If your managed configuration requires explicit values, change only that line to code_mode_host = true after confirming policy allows it.

The current OpenAI Codex feature registry marks code_mode_host as stable and enabled by default. Removing an old opt-out is therefore preferable to copying a large replacement config from another machine.

Restart Codex completely, then repeat:

codex features list | grep '^code_mode_host[[:space:]]'
codex doctor

Start a fresh task and run the same read-only pwd check. Success means the feature list reports the host enabled, the doctor check does not report a host failure, and the command executes in the expected directory.

If you are comparing the Desktop app with a terminal session, confirm both use the same repository, profile, and Codex home. The Codex App versus CLI workflow guide explains why two surfaces can otherwise appear to disagree.

Separate a Disabled Host From a Missing Host

After enabling the feature, you may instead see an error such as:

failed to spawn code-mode host ... No such file or directory

That is not the same failure. The feature is enabled, but Codex cannot resolve or launch its companion executable. OpenAI's package-builder documentation shows that supported packages include codex-code-mode-host beside the main entrypoint, and an earlier issue documents missing-host failures across multiple installation attempts.

Preserve these diagnostics:

command -v codex
which -a codex
codex --version
codex doctor

Then follow the installation manager that owns the first resolved codex executable. Do not download an arbitrary helper binary, create a fake executable, or copy a host from another version. If more than one Codex installation is present, prove which one launches before updating or removing anything.

For a separate hang where tool execution starts but never completes, use the Codex running-command diagnostic instead.

Avoid These False Fixes

• Do not delete ~/.codex or reset all Codex state for one feature override.

• Do not repeatedly reinstall Codex before checking the effective feature value.

• Do not remove the entire [features] table.

• Do not run with disabled approvals or sandboxing to work around a host configuration error.

• Do not copy another person's config, profile, helper binary, or private runtime path.

• Do not claim the regression is fixed upstream while issue 37376 remains open.

• Do not post tokens, private paths, or full configuration files in a public issue.

The repair should remain reversible and attributable: one temporary enable, one reviewed setting change, one fresh-session verification.

Verify Restored Tool Access With Aident Loadout

Aident Loadout provides a bounded way to test several read-only tool steps without putting a provider key in your prompt. Give Codex the canonical setup instruction:

Follow https://aident.ai/SETUP.md

Then use this prompt:

Check my Aident Loadout account and Vault status. Search the staging capability catalog for a connected read-only Hacker News search Action, inspect its current schema, and preflight it. If the estimate is free, search for "Codex code mode host" and return only the matching titles and URLs. Do not publish, comment, edit, install, change files, or ask me for a provider key.

Success is measurable: the account, Vault, catalog, schema, preflight, and read-only search steps complete without the code-mode-host error; no external write occurs; and no credential appears in output. Ready to verify the repaired tool path? Set up Aident Loadout and run the read-only check.

Sources

• OpenAI Codex issue 37376: 0.147.0 fails all tools with an existing code_mode_host=false override

• OpenAI Codex configuration basics

• OpenAI Codex feature registry

• OpenAI Codex package-builder documentation

• OpenAI Codex issue 31863: codex-code-mode-host is missing

Refresh this guide when issue 37376 changes state, Codex changes the default or maturity of code_mode_host, startup validation gains a supported fallback, or the installation layout for codex-code-mode-host changes.