0.144.0: codex-code-mode-host is missing

0.144.0 / pro / any model / macos

What issue are you seeing?

Codex CLI doesn't work at all. Rather, it complains:

I’m blocked by the local Codex command runner: ~/.local/bin/codex-code-mode-host is missing. No commands ran and no files, commits, branches, or PRs were changed.

Please restore/reinstall that binary or restart Codex.

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

Windows CLI install misses sandbox helper/command runner placement, causing CreateProcessWithLogonW failed: 2 #30856
Windows app sandbox helpers are packaged under resources but launcher searches app/PATH #30732

Powered by Codex Action

on apple silicon, seems like it got placed in

~/.codex/packages/standalone/releases/0.144.0-aarch64-apple-darwin/bin/codex-code-mode-host

symlinking fixes it for now

ln -s ~/.codex/packages/standalone/releases/0.144.0-aarch64-apple-darwin/bin/codex-code-mode-host ~/.local/bin/codex-code-mode-host

I solved it with clade code lol, here is what worked for me:

Root cause looks like helper resolution off the un-canonicalized current_exe() — same class as #30732 / #30856, which hit the sandbox helpers on Windows.

The standalone installer creates ~/.local/bin/codex -> ~/.codex/packages/standalone/current/bin/codex (per #17022). codex-code-mode-host ships next to the real binary and is intentionally not placed on PATH. But the spawner resolves the helper as a sibling of current_exe(), and on macOS that returns the symlink path rather than its target — so it looks in ~/.local/bin/ and finds nothing. Neither fallback saves it: the packaged codex-resources/ contains only the bundled zsh.

Notably, codex doctor reports install: consistent and correctly resolves bin to the release directory, while printing executable: ~/.local/bin/codex. So the two code paths disagree — doctor canonicalizes, the spawner doesn't.

Minimal A/B on 0.144.0, macOS aarch64. Same binary, two invocation paths:

$ ~/.local/bin/codex exec --sandbox read-only "Run: git rev-parse --abbrev-ref HEAD. Report only its exact output."
ERROR codex_core::tools::router: error=failed to spawn code-mode host
  /Users/.../.local/bin/codex-code-mode-host: No such file or directory (os error 2)
codex
main

$ ~/.codex/packages/standalone/current/bin/codex exec --sandbox read-only "Run: git rev-parse --abbrev-ref HEAD. Report only its exact output."
exec /bin/zsh -lc 'git rev-parse --abbrev-ref HEAD' ... succeeded in 1549ms:
master

codex
master

Since code_mode_host is stable and enabled by default, this breaks every tool call on standalone installs.

The more severe bug is the second-order failure

In the first run there is no exec block at all. The helper spawn fails, the error is logged — and then the turn continues and the model answers from nothing. It reported the branch as main. The actual branch is master.

A tool-host spawn failure is being surfaced to the model as something it can proceed past, so a hard infrastructure error degrades into a silently fabricated tool result. That seems worth separating from the install bug: even after the path issue is fixed, a helper that dies mid-session would presumably produce the same class of invented output.

Workarounds

No reinstall needed — the helper is already on disk, just not where the spawner looks.

Put ~/.codex/packages/standalone/current/bin ahead of ~/.local/bin on PATH (note: ~/.zshrc is only read by interactive shells, so non-interactive/GUI launches still break), or
symlink the packaged helper into ~/.local/bin/, or
set CODEX_CODE_MODE_HOST_PATH to the packaged helper.

Suggested fix

Canonicalize current_exe() before the sibling lookup — matching what doctor already does — and fail the turn when the helper cannot spawn, rather than letting the model answer without its tools.

symlinking fixes it for now

Can confirm that symlinking works

Completely broken on archlinux as well, with no opportunity to symlink if installed directly from the arch packages, because that bin doesn't exist anywhere in .codex either.

I assume this PR (and related) are supposed to fix: #31858

Completely broken on archlinux as well, with no opportunity to symlink if installed directly from the arch packages, because that bin doesn't exist anywhere in .codex either.

You can download codex-code-mode-host from releases and place it to /usr/bin/codex-code-mode-host after decompress, such as: https://github.com/openai/codex/releases/download/rust-v0.144.0/codex-code-mode-host-x86_64-unknown-linux-musl.tar.gz

Download, extract and run:

sudo install -m 0755 codex-code-mode-host-x86_64-unknown-linux-musl /usr/bin/codex-code-mode-host

Working on a fix for this, submitting a PR shortly

Root cause

default_host_program() in codex-rs/code-mode/src/remote_session.rs passes std::env::current_exe() directly to resolve_host_program(), which derives the host path as a sibling of the exe. On macOS, current_exe() is backed by _NSGetExecutablePath and returns the invocation path (the symlink), not its target.

The standalone installer creates ~/.local/bin/codex as a symlink to ~/.codex/packages/standalone/current/bin/codex but does not create a matching codex-code-mode-host symlink. So the sibling lookup resolves to ~/.local/bin/codex-code-mode-host — which doesn't exist — and every tool call fails before execution.

The host binary is on disk at ~/.codex/packages/standalone/current/bin/codex-code-mode-host, just not where the resolver looks for it.

Proposed fix

Canonicalize current_exe before the sibling lookup:

fn default_host_program() -> PathBuf {
    let current_exe =
        std::env::current_exe().map(|exe| dunce::canonicalize(&exe).unwrap_or(exe));
    resolve_host_program(std::env::var_os(CODE_MODE_HOST_PATH_ENV), current_exe)
}

dunce::canonicalize is already used throughout the workspace (e.g. windows-sandbox-rs, path-utils, core). The pure resolve_host_program function stays unchanged — canonicalization happens at the call site, which is the filesystem boundary.

The unwrap_or(exe) fallback preserves the current behavior if canonicalization fails.

This is the same class of bug as #30732 / #30856 (Windows sandbox helpers resolved current_exe() without canonicalization).

Workarounds

Any of these unblocks tool execution until the fix lands:

ln -s ~/.codex/packages/standalone/current/bin/codex-code-mode-host ~/.local/bin/codex-code-mode-host
export CODEX_CODE_MODE_HOST_PATH=~/.codex/packages/standalone/current/bin/codex-code-mode-host
Put ~/.codex/packages/standalone/current/bin ahead of ~/.local/bin on PATH

FWIW, I also see this with 0.144.0 on Windows, but the workaround doesn't apply as there isn't a codex-code-mode-host.exe anywhere in %USERPROFILE%\.codex as with the macOS workaround, nor anywhere in %USERPROFILE%\scoop. Installed via scoop and codex doctor doesn't find anything wrong, but GPT 5.6 Sol is unable to access local files, reporting that "the tool adapter expects codex-code-mode-host.exe".

FWIW, I also see this with 0.144.0 on Windows, but the workaround doesn't apply as there isn't a codex-code-mode-host.exe anywhere in %USERPROFILE%\.codex as with the macOS workaround. Installed via scoop and codex doctor doesn't find anything wrong, but GPT 5.6 Sol is unable to access local files, reporting that "the tool adapter expects codex-code-mode-host.exe".

Well not only on windows. Same issue on arch linux where the file simply does not exist when using the official package so there is nothing to symlink.
The maintainer says the issue is with codex itself not the package which has been confirmed by the issue not being arch specific.
The archlinux package issue:
https://gitlab.archlinux.org/archlinux/packaging/packages/openai-codex/-/work_items/49

Hit this issue after switching back to codex after a while and riiiiight back to claude i go

Additional Linux/Homebrew data point.

Environment:

Ubuntu 24.04
Codex CLI 0.144.0
Install method: Homebrew cask under Linuxbrew
Binary path: /home/linuxbrew/.linuxbrew/Caskroom/codex/0.144.0/codex-x86_64-unknown-linux-musl
Model: gpt-5.6-sol

Observed behavior:

Normal chat responses worked.
Agent management worked.
All shell/tool execution failed before the command ran, including pwd and true.
The same failure reproduced in the parent agent, existing subagents, and newly spawned subagents.
gh itself was installed and authenticated, but gh could not be reached from affected agents because the tool host failed first.

Errors observed:

failed to spawn code-mode host /home/linuxbrew/.linuxbrew/Caskroom/codex/0.144.0/codex-code-mode-host: No such file or directory (os error 2)

After manually symlinking codex-code-mode-host to codex-x86_64-unknown-linux-musl, the missing-file error changed to:

code-mode host exited during handshake

That symlink did not fix the issue, presumably because the regular CLI binary does not behave as a valid code-mode host entrypoint when invoked under that name.

Homebrew cask contents after brew reinstall --cask codex:

/home/linuxbrew/.linuxbrew/Caskroom/codex/0.144.0/codex-x86_64-unknown-linux-musl

No codex-code-mode-host binary was present anywhere under the cask directory.

codex doctor reported the install as broadly healthy, and websocket/auth checks passed, so the issue was isolated to the code-mode host execution path.

Workaround that restored shell/tool execution:

[features]
code_mode_host = false

After disabling code_mode_host, newly spawned agents could run:

pwd
true
command -v gh
gh auth status

successfully.

Using codex -c features.code_mode_host=false seems to be a workaround for me before the upstream fix

For Homebrew users: opened Homebrew/homebrew-cask#274197 switching the cask to the codex-package-<arch>-<os>.tar.gz release asset, which already contains both bin/codex and bin/codex-code-mode-host. Tested end-to-end on Apple Silicon — tool execution works again with no code-mode host spawn errors.

@etraut-openai

Thanks for reporting the issue. We're working on a fix.

@etraut-openai can you expand on what the "fix" is? Do downstream packages need to change how they build from source? In a later comment you said you were fixing "for homebrew", does that mean a new release of Codex to solve it or changes to how Homwbrew's Codex formula works?

https://github.com/openai/codex/actions/runs/29053738151 is the build for the 0.144.1 hotfix that should fix the Homebrew release.

For Homebrew users: opened Homebrew/homebrew-cask#274197 switching the cask to the codex-package-<arch>-<os>.tar.gz release asset, which already contains both bin/codex and bin/codex-code-mode-host. Tested end-to-end on Apple Silicon — tool execution works again with no code-mode host spawn errors.

FWIW this was previously done for the homebrew cask and it caused some issues so was backed out. We're still figuring out how to make the new packaging strategy compatible with Apple's signing requirements and will follow up to update the cask when it's ready. I would not recommend using this approach right now.

A short term workaround until version 0.144.1 lands in homebrew: you can download the released codex-code-mode-host-* from the latest release https://github.com/openai/codex/releases/tag/rust-v0.144.0 and colocate the binary with your current codex binary.

Easy mode workaround for MacOS users (using Darwin) who installed with homebrew:

curl -L https://github.com/openai/codex/releases/download/rust-v0.144.0/codex-code-mode-host-x86_64-apple-darwin.tar.gz -o /tmp/codex-code-mode-host.tar.gz && \
tar -xzf /tmp/codex-code-mode-host.tar.gz -C /tmp && \
sudo mv /tmp/codex-code-mode-host-x86_64-apple-darwin /opt/homebrew/bin/codex-code-mode-host && \
sudo chmod +x /opt/homebrew/bin/codex-code-mode-host

Tip

For Windows NPM / Node Users the codex-code-mode-host.exe is located here:

%APPDATA%\Roaming\npm\node_modules\@openai\codex\node_modules\@openai\codex-win32-x64\vendor\x86_64-pc-windows-msvc\bin

All you need to do is copy the codex-code-mode-host.exe to %USERPROFILE%\.codex\plugins\.plugin-appserver\

after that, everything works.

Additional confirmation from macOS ARM64 with Codex CLI 0.144.0 installed via Homebrew:

The workspace client fails when it attempts to spawn /opt/homebrew/bin/codex-code-mode-host (No such file or directory (os error 2)).
codex doctor --summary --no-color reports 17 ok · 1 idle · 0 warn · 0 fail, including install: consistent.
The Homebrew cask provides the codex binary but not the separate code-mode host expected at that path.
Repository state and ~/.codex reset are unrelated; the terminal CLI can launch independently.

This also suggests codex doctor should validate that the code-mode host required by the active workspace/client path exists and is executable.

Guys I ask you to please read the issue in its entirety before posting comments, there is a lot of duplicated info/messages and it only clutters this thread.
If you don't have anything new just don't comment please, thank you.
I have no authority, I am just kindly asking you to keep it to the theme here.

Homebrew/homebrew-cask#274225 updates homebrew to point at 0.144.1 which we expect to resolve the issue for brew users.

Navigation Menu

Repository navigation

0.144.0: codex-code-mode-host is missing #31831

What issue are you seeing?

The more severe bug is the second-order failure

Workarounds

Suggested fix

Root cause

Proposed fix

Workarounds

7 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

0.144.0: codex-code-mode-host is missing #31831

Description

What issue are you seeing?

Activity

github-actions commented on Jul 9, 2026

tyler-lloyd commented on Jul 9, 2026

MoJony commented on Jul 9, 2026

The more severe bug is the second-order failure

Workarounds

Suggested fix

PaulRBerg commented on Jul 9, 2026

Sushisource commented on Jul 9, 2026

mustafa0x commented on Jul 9, 2026

littleya commented on Jul 9, 2026

GithubUser5462 commented on Jul 9, 2026

morluto commented on Jul 9, 2026

morluto commented on Jul 9, 2026

Root cause

Proposed fix

Workarounds

smithwinston commented on Jul 9, 2026

ChromMob commented on Jul 9, 2026

7 remaining items

mattpodolak commented on Jul 9, 2026

disneyLadySango commented on Jul 9, 2026

krinoid commented on Jul 9, 2026

anh-sunbound commented on Jul 9, 2026

austinbutler commented on Jul 9, 2026

bolinfest commented on Jul 9, 2026

anp-oai commented on Jul 9, 2026

cconger commented on Jul 9, 2026

johnbindel commented on Jul 9, 2026

Nick2bad4u commented on Jul 9, 2026

renoirvieir4 commented on Jul 9, 2026

ChromMob commented on Jul 9, 2026

anp-oai commented on Jul 9, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions