AskMeAnything
Ask
Ask
25
@brew_cask_user ·

codex-code-mode-host is missing: every command fails after 0.144.0

Updated the Codex CLI and now nothing it tries to run actually runs.

Chat still works. It answers normally. But the moment it wants to touch the shell I get back:

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.

Other times it surfaces as failed to spawn codex-code-mode-host.

It is not selective. pwd fails. true fails. So it is not a permissions problem with a particular command, nothing is being spawned at all.

I installed through Homebrew, and there is a codex binary in /opt/homebrew/bin but no codex-code-mode-host next to it. Restarting and reinstalling the same version changes nothing, which makes sense if the file was never there.

Is the binary supposed to ship with the CLI, or am I meant to install it separately?

9 answers Share
Report

9 answers

BestTopNewOldControversial

Answering anonymously, a moderator will review it first.

  • @flag_hunter · 2w ago
    @flag_hunter ·

    If you need it working right now without waiting on packaging:

    codex -c features.code_mode_host=false

    That turns off the code mode host and puts command execution back on the path that does not need the extra binary. It is a workaround rather than a fix, so take it out once your install has the file.

    28
    Share
    Reply

    Answering anonymously, a moderator will review it first.

    Report
  • @release_asset · 2w ago · 3 replies
    @release_asset ·

    It ships with the CLI, and in 0.144.0 it did not.

    The release publishes two kinds of asset. There is a bare codex binary for the architecture, and there is a codex-package-<arch>-<os>.tar.gz that contains a bin/ directory holding both codex and codex-code-mode-host. The Homebrew cask was pointing at the bare binary, so the install produced a working codex with its command runner absent.

    So nothing on your machine is broken and reinstalling the same version cannot help. The package you were given is short one file.

    30
    Share
    Reply

    Answering anonymously, a moderator will review it first.

    Report
    • @brew_cask_user · 2w ago · 2 replies
      @brew_cask_user OP ·

      That explains why reinstalling felt so pointless. Same tarball, same missing file.

      17
      Share
      Reply

      Answering anonymously, a moderator will review it first.

      Report
      • @release_asset · 2w ago
        @release_asset ·

        The cask was switched over to the package tarball afterwards, which is the actual fix. If you update and ls /opt/homebrew/bin | grep code-mode shows the host binary, you have the corrected cask and the flag below is no longer needed.

        19
        Share
        Reply

        Answering anonymously, a moderator will review it first.

        Report
  • @pinned_versions · 2w ago · 2 replies
    @pinned_versions ·

    Other route if you install from the tarball yourself: pull codex-package-<arch>-<os>.tar.gz from the release page and put both files from its bin/ directory on your path together. The two are a pair. Copying only codex across reproduces this exact error on a clean machine.

    18
    Share
    Reply

    Answering anonymously, a moderator will review it first.

    Report
    • @flag_hunter · 2w ago
      @flag_hunter ·

      Worth checking ~/.local/bin as well as the brew prefix, since the message names that path and a stale copy there can shadow the good one.

      1
      Share
      Reply

      Answering anonymously, a moderator will review it first.

      Report
  • @linuxbrew_ana · 2w ago
    @linuxbrew_ana ·

    Same failure on Ubuntu through Linuxbrew, so it is not a macOS thing. The binary sat at /home/linuxbrew/.linuxbrew/Caskroom/codex/0.144.0/codex-x86_64-unknown-linux-musl with no host binary anywhere near it.

    Worth adding: it failed in the parent agent, in subagents that already existed, and in newly spawned ones. Everything that wants a shell goes through the same spawn.

    21
    Share
    Reply

    Answering anonymously, a moderator will review it first.

    Report
  • @shell_tools_ro · 2w ago
    @shell_tools_ro ·

    Quickest way to tell this apart from a sandbox or permissions problem: ask it to run pwd. If that fails too, it is the spawn, not the command.

    1
    Share
    Reply

    Answering anonymously, a moderator will review it first.

    Report
  • @linuxbrew_ana · 2w ago
    @linuxbrew_ana ·

    A CLI that answers questions but cannot run anything is a very expensive rubber duck.

    1
    Share
    Reply

    Answering anonymously, a moderator will review it first.

    Report