I updated Codex CLI expecting the usual experience:

codex

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).

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

The last version that worked normally for me was:

codex-cli 0.156.1

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

Error: Access is denied. (os error 5)

and:

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

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

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

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

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.

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

npm install -g @openai/codex@0.156.1

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

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
+                                             ~~~

At this point I had gone from:

Codex upgrade problem

to:

Codex downgrade problem

😅

The key detail was my shell version.

I checked:

$PSVersionTable.PSVersion

and discovered I was still running:

Windows PowerShell 5.1

The current Codex Windows installer performs architecture detection using:

[System.Runtime.InteropServices.RuntimeInformation]::OSArchitecture

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

That installed:

PowerShell 7.6.6

Then I opened PowerShell 7:

pwsh

and verified it:

$PSVersionTable.PSVersion

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"

Then ran the official installer:

irm https://chatgpt.com/codex/install.ps1 | iex

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"
}

So:

$env:CODEX_RELEASE="0.156.1"

means:

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

After installation:

codex --version

should report:

codex-cli 0.156.1

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

If it reports:

codex-cli 0.157.0

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

Option 1 — Temporary workaround

codex --no-daemon

This keeps you working without the background daemon.

Option 2 — Disable automatic daemon startup

In your Codex configuration:

[features]
daemon_auto_start = false

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

For standalone installations, I recommend PowerShell 7.

Install PowerShell:

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

Start it:

pwsh

Then:

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

Verify:

codex --version

Expected:

codex-cli 0.156.1

Then optionally clean up the temporary environment variable:

Remove-Item Env:CODEX_RELEASE

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

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

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

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.

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)

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

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.

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

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

Stable rollback reported by multiple users:

Codex CLI 0.156.1

For npm:

npm install -g @openai/codex@0.156.1

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

And if you're seeing:

The property 'OSArchitecture' cannot be found

check whether you're still running Windows PowerShell 5.1.

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

References

• OpenAI Codex issue #48043 — Codex CLI 0.157.0 daemon regression
• OpenAI Codex Windows installer source
• OpenAI Codex GitHub repository

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

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. 😄