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. 😄
Top comments (0)