DEV Community

Cover image for Codex CLI 0.157.0 Broke on Windows — Here’s How I Got Back to Work [DO NOT UPDATE CODEX !! ]
Sanu Khan
Sanu Khan

Posted on

Codex CLI 0.157.0 Broke on Windows — Here’s How I Got Back to Work [DO NOT UPDATE CODEX !! ]

I updated Codex CLI expecting the usual experience:

codex
Enter fullscreen mode Exit fullscreen mode

Instead, Codex stopped starting normally.

The update had introduced a background daemon, and on my Windows machine it immediately failed with:

Installing daemon from CLI version 0.157.0 into C:\Users\<USER>\.codex\packages\app-server-daemon...
Error: Access is denied. (os error 5)

To work without the background server, rerun the same command with --no-daemon
(including resume or fork and its arguments).
Enter fullscreen mode Exit fullscreen mode

My first reaction was the usual Windows debugging checklist:

Is this a permissions problem?
Is Defender blocking something?
Is a process holding the daemon executable?
Did I somehow launch PowerShell as administrator?

But after checking the Codex repository, it became clear I wasn't the only one.

There is now an open GitHub issue tracking the problem:

openai/codex #48043 — Codex CLI 0.157.0 fails to start on Windows with daemon privilege error

And the interesting part is that there are actually a few variations of the same problem.


What changed in Codex CLI 0.157.0?

The affected release is:

codex-cli 0.157.0
Enter fullscreen mode Exit fullscreen mode

The last version that worked normally for me was:

codex-cli 0.156.1
Enter fullscreen mode Exit fullscreen mode

On 0.157.0, users in the GitHub issue reported daemon-related startup failures including:

Error: Access is denied. (os error 5)
Enter fullscreen mode Exit fullscreen mode

and:

Error: start the Windows daemon from a non-elevated terminal;
shared clients must not inherit administrator privileges
Enter fullscreen mode Exit fullscreen mode

The important detail here is the new/shared background daemon.

Codex is trying to prevent an unsafe privilege boundary where a shared daemon running with administrator privileges could be inherited by non-admin clients.

That security concern makes sense.

The UX problem is what happens next:

if the daemon cannot start, the interactive Codex CLI can fail to start with it.


The temporary workaround: --no-daemon

Codex itself tells you about one workaround:

codex --no-daemon
Enter fullscreen mode Exit fullscreen mode

And yes — it worked for me.

So technically I could continue working.

But there was a catch.

The CLI felt noticeably slower compared with my previous setup where the background server was available.

That made --no-daemon useful as an emergency workaround, but not something I wanted to use as my normal development setup.

Another workaround reported in the GitHub discussion is disabling automatic daemon startup in the Codex configuration:

[features]
daemon_auto_start = false
Enter fullscreen mode Exit fullscreen mode

That lets Codex operate without automatically starting the shared daemon.

Again: useful workaround, but it doesn't really solve the regression.


Then I tried the obvious fix: downgrade

At that point I decided to go back to the version that had been working perfectly well:

0.156.1
Enter fullscreen mode Exit fullscreen mode

Several users in the GitHub issue confirmed the same result:

Downgrading to 0.156.1 restores normal operation.

I tested it myself.

And sure enough:

0.156.1 works.
Enter fullscreen mode Exit fullscreen mode

If you installed Codex through npm, the rollback is simple:

npm install -g @openai/codex@0.156.1
Enter fullscreen mode Exit fullscreen mode

But my Codex installation wasn't managed through npm.

I was using the newer standalone Codex CLI installer.

And that's where Windows gave me a second surprise.


The second bug: the standalone installer + Windows PowerShell 5.1

The standalone Windows installer supports pinning a specific Codex release.

So I tried:

$env:CODEX_RELEASE="0.156.1"

irm https://chatgpt.com/codex/install.ps1 | iex
Enter fullscreen mode Exit fullscreen mode

Instead of installing Codex, PowerShell returned:

iex : The property 'OSArchitecture' cannot be found on this object.
Verify that the property exists.

At line:1 char:45
+ irm https://chatgpt.com/codex/install.ps1 | iex
+                                             ~~~
Enter fullscreen mode Exit fullscreen mode

At this point I had gone from:

Codex upgrade problem
Enter fullscreen mode Exit fullscreen mode

to:

Codex downgrade problem
Enter fullscreen mode Exit fullscreen mode

😅

The key detail was my shell version.

I checked:

$PSVersionTable.PSVersion
Enter fullscreen mode Exit fullscreen mode

and discovered I was still running:

Windows PowerShell 5.1
Enter fullscreen mode Exit fullscreen mode

The current Codex Windows installer performs architecture detection using:

[System.Runtime.InteropServices.RuntimeInformation]::OSArchitecture
Enter fullscreen mode Exit fullscreen mode

On my PowerShell 5.1 environment, that architecture lookup failed.

So rather than patching the installer locally or switching my Codex installation over to npm, I fixed the shell environment.


Installing PowerShell 7

I installed the current PowerShell release using winget:

winget install --id Microsoft.PowerShell --source winget
Enter fullscreen mode Exit fullscreen mode

That installed:

PowerShell 7.6.6
Enter fullscreen mode Exit fullscreen mode

Then I opened PowerShell 7:

pwsh
Enter fullscreen mode Exit fullscreen mode

and verified it:

$PSVersionTable.PSVersion
Enter fullscreen mode Exit fullscreen mode

Now I had a modern PowerShell environment for the standalone installer.


Downgrading the standalone Codex CLI to 0.156.1

From PowerShell 7, I pinned the Codex release:

$env:CODEX_RELEASE="0.156.1"
Enter fullscreen mode Exit fullscreen mode

Then ran the official installer:

irm https://chatgpt.com/codex/install.ps1 | iex
Enter fullscreen mode Exit fullscreen mode

The installer itself supports the CODEX_RELEASE environment variable.

The relevant part of OpenAI's installer currently looks like this:

param(
    [string]$Release = $env:CODEX_RELEASE
)

if ([string]::IsNullOrWhiteSpace($Release)) {
    $Release = "latest"
}
Enter fullscreen mode Exit fullscreen mode

So:

$env:CODEX_RELEASE="0.156.1"
Enter fullscreen mode Exit fullscreen mode

means:

Install exactly Codex CLI 0.156.1 rather than resolving the latest release.

After installation:

codex --version
Enter fullscreen mode Exit fullscreen mode

should report:

codex-cli 0.156.1
Enter fullscreen mode Exit fullscreen mode

And that's the version I went back to.


The complete Windows workaround

If you're running into this problem today, here's the shortest version.

If you're on Codex CLI 0.157.0

Check:

codex --version
Enter fullscreen mode Exit fullscreen mode

If it reports:

codex-cli 0.157.0
Enter fullscreen mode Exit fullscreen mode

and normal startup fails with a daemon error, you have a few options.

Option 1 — Temporary workaround

codex --no-daemon
Enter fullscreen mode Exit fullscreen mode

This keeps you working without the background daemon.


Option 2 — Disable automatic daemon startup

In your Codex configuration:

[features]
daemon_auto_start = false
Enter fullscreen mode Exit fullscreen mode

This was confirmed by another Windows user in the GitHub discussion.


Option 3 — Roll back to 0.156.1

For npm installations:

npm install -g @openai/codex@0.156.1
Enter fullscreen mode Exit fullscreen mode

For standalone installations, I recommend PowerShell 7.

Install PowerShell:

winget install --id Microsoft.PowerShell --source winget
Enter fullscreen mode Exit fullscreen mode

Start it:

pwsh
Enter fullscreen mode Exit fullscreen mode

Then:

$env:CODEX_RELEASE="0.156.1"
irm https://chatgpt.com/codex/install.ps1 | iex
Enter fullscreen mode Exit fullscreen mode

Verify:

codex --version
Enter fullscreen mode Exit fullscreen mode

Expected:

codex-cli 0.156.1
Enter fullscreen mode Exit fullscreen mode

Then optionally clean up the temporary environment variable:

Remove-Item Env:CODEX_RELEASE
Enter fullscreen mode Exit fullscreen mode

Don't immediately run PowerShell as Administrator

One thing worth highlighting from the GitHub thread:

running the terminal elevated can actually be part of the problem.

One reported error specifically says:

start the Windows daemon from a non-elevated terminal;
shared clients must not inherit administrator privileges
Enter fullscreen mode Exit fullscreen mode

So if your instinct is:

Access denied? I'll just run PowerShell as Administrator.

That may move you directly into the other daemon protection check.

For normal Codex usage, try a standard, non-elevated PowerShell session first.

There is also an interesting edge case documented in the issue where a Windows machine had UAC completely disabled.

On that machine, there effectively wasn't a normal non-elevated token available at all.

In that configuration, telling the user to "open a non-elevated terminal" isn't really actionable.

The user confirmed that:

codex --no-daemon
Enter fullscreen mode Exit fullscreen mode

still worked.

They also suggested that Codex could fall back to its embedded server when daemon startup is rejected rather than terminating the interactive CLI entirely.

That seems like a much smoother failure mode.


Interestingly, this may not be Windows-only

Most of issue #48043 revolves around Windows, and the issue itself currently carries the windows-os label.

However, one user also reported:

Same error on Linux. Reverting to 0.156.1 fixes it.

That's only one report in this particular discussion, so I wouldn't conclude yet that every platform is affected by the same underlying bug.

But it does suggest the regression may involve more than a single Windows permission edge case.


What I'd like to see improved

There are really two separate developer-experience problems here.

1. Daemon startup should fail gracefully

Protecting privilege boundaries is the correct thing to do.

But if the optional/background daemon cannot start, the CLI could potentially fall back automatically rather than making:

codex
Enter fullscreen mode Exit fullscreen mode

unusable.

Something like:

Unable to start shared daemon because this terminal is elevated.

Falling back to embedded server.

Run from a non-elevated terminal to enable the shared daemon.
Enter fullscreen mode Exit fullscreen mode

would be considerably easier to understand.


2. The error needs to identify the failing operation

For the os error 5 case:

Error: Access is denied. (os error 5)
Enter fullscreen mode Exit fullscreen mode

isn't enough information to diagnose the problem properly.

Was Codex trying to:

  • create a directory?
  • replace an executable?
  • delete an old daemon?
  • rename a file?
  • open a named pipe/socket?
  • overwrite a locked binary?
  • change permissions?

Knowing the exact path and Windows operation would make troubleshooting dramatically easier.

Instead of:

Access is denied
Enter fullscreen mode Exit fullscreen mode

something closer to:

Unable to replace:
C:\Users\<USER>\.codex\packages\app-server-daemon\codex.exe

Windows returned ERROR_ACCESS_DENIED (5).

The file may currently be in use.
Enter fullscreen mode Exit fullscreen mode

would save a lot of debugging time.


What started as a simple upgrade...

The funny part is that this started with something completely routine:

Update Codex CLI.

Then the chain became:

Upgrade to 0.157.0
        ↓
Codex daemon fails
        ↓
Try --no-daemon
        ↓
Works, but slower
        ↓
Decide to downgrade
        ↓
Standalone installer fails under PowerShell 5.1
        ↓
Install PowerShell 7
        ↓
Pin Codex to 0.156.1
        ↓
Back to coding
Enter fullscreen mode Exit fullscreen mode

That's software development in a nutshell.

Sometimes the tool you're using to fix the tool needs fixing first. 😄


TL;DR

If Codex CLI 0.157.0 suddenly stopped working on Windows, you're not necessarily dealing with a broken local project or corrupted Codex configuration.

There is an active upstream issue involving the new daemon behavior.

Temporary workaround:

codex --no-daemon
Enter fullscreen mode Exit fullscreen mode

Stable rollback reported by multiple users:

Codex CLI 0.156.1
Enter fullscreen mode Exit fullscreen mode

For npm:

npm install -g @openai/codex@0.156.1
Enter fullscreen mode Exit fullscreen mode

For the standalone Windows installation:

winget install --id Microsoft.PowerShell --source winget
pwsh

$env:CODEX_RELEASE="0.156.1"
irm https://chatgpt.com/codex/install.ps1 | iex

codex --version
Enter fullscreen mode Exit fullscreen mode

And if you're seeing:

The property 'OSArchitecture' cannot be found
Enter fullscreen mode Exit fullscreen mode

check whether you're still running Windows PowerShell 5.1.

Moving to PowerShell 7 solved that part of the installation path for me.


References


If you landed here because 0.157.0 broke your Codex setup too, add your environment and exact error to the GitHub issue.

Especially include:

OS
Codex CLI version
Installation method
Shell + shell version
Whether terminal is elevated
Exact daemon error
Whether --no-daemon works
Whether 0.156.1 works
Enter fullscreen mode Exit fullscreen mode

The more reproducible environments upstream has, the easier it is to distinguish a permissions problem from a genuine release regression.

Happy coding — and maybe don't hit latest five minutes before an important deployment. 😄

Top comments (0)