Codex CLI on Windows won't start after 0.157.0: `Error: Access is denied. (os error 5)` / `start the Windows daemon from a non-elevated terminal` (background server daemon)

Context

Source(s): https://juejin.cn/post/7695747621059575858 (Juejin write-up with the error and the two no-daemon workarounds); fixes confirmed by commenters in https://github.com/openai/codex/issues/48043 and https://github.com/openai/codex/issues/51283 Status: reported working by source, not reproduced by us.

Problem

Starting with Codex CLI 0.157.0, plain codex on Windows exits immediately with one of the errors above instead of opening the TUI (terminal UI). Reports in the upstream threads continue through 0.158.0, 0.159.x, 0.160.x, 0.161.0 and 0.162.x. One commenter saw the TUI open briefly and then close; running codex --no-alt-screen showed the error.

Error (redacted / normalized)

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

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

Error: failed to open daemon process: Access is denied. (os error 5)

Applies when

Windows 10/11 x64, PowerShell or cmd, Codex CLI 0.157.0 and later installed with npm or the standalone installer. The "non-elevated terminal" variant appears when the terminal runs with an administrator token, including machines where UAC is turned off (EnableLUA = 0), where every terminal is elevated even if it was not opened with "Run as administrator". A few commenters reported similar daemon errors on Linux, WSL and macOS; this card only covers Windows. On 0.162.1 one commenter (UAC off) got Running as administrator: shared background server disabled. To enable it, restart Codex in a terminal without administrator permissions. instead of the error, so on that version an elevated terminal seems to start Codex without the shared server instead of exiting (our inference). The Access is denied variants were still reported on 0.162.1.

Confirm it is this problem

1. Run codex --version and then codex → expect: a version of 0.157.0 or later, and one of the error lines above containing --no-daemon or non-elevated terminal.
2. Run codex --no-daemon → expect: the TUI starts. If it does, the failure is in the shared background server, not your login, network or config.

Not this when / boundary

If codex --no-daemon also fails with error 5, the problem is not the shared server (a separate upstream report, issue 54118, describes the no-daemon app server exiting with error 5 on 0.162.1), so this card does not cover it. Errors that appear only when Codex runs a command (sandbox setup errors) are a different problem (our inference).

Root cause

Since 0.157.0 the CLI connects to one shared background "app server" process (the daemon) instead of starting its own, so several sessions can see each other's work (a Codex contributor described this in issue 48043). Codex refuses to start that shared server from an elevated process, because ordinary sessions could then run commands with administrator rights. The Access is denied variants are separate defects in installing or reconnecting to the daemon: one commenter traced the installer variant to a folder rename with no retry, and another, after having Codex read its own logs, traced failed to open daemon process to a stale daemon record whose process ID had been reused by a protected Windows process (Windows Defender). Upstream has not announced a fixed release; both issues were still open when checked.

Variables

<state dir>: your Codex home folder, by default %USERPROFILE%\.codex (or the folder in CODEX_HOME if you set it).

Fix

1. Quick unblock, every variant: start with codex --no-daemon (add it to resume and fork commands too). → expect: Codex starts. Several commenters confirmed this; one reported it was the only thing that worked on 0.159.3.
2. To make that permanent, add daemon_auto_start = false under a [features] section in config.toml in <state dir>. → expect: plain codex starts without the shared server. One commenter confirmed this on 0.157.0 in an elevated PowerShell.
3. For non-elevated terminal: if your account can get a normal token, open PowerShell normally (not "Run as administrator") and run codex. If UAC is off, there is no non-elevated terminal, so stay with step 1 or 2 (described by the Juejin author and by commenters with UAC off).
4. For failed to open daemon process: Access is denied: close all Codex and VS Code sessions, then rename (don't delete) the two daemon state folders in PowerShell: $stamp = Get-Date -Format "yyyyMMdd-HHmmss"; foreach ($name in @("app-server-control", "app-server-daemon")) { $path = Join-Path $HOME ".codex\$name"; if (Test-Path $path) { Rename-Item -LiteralPath $path -NewName "$name.backup-$stamp" } }. Then run codex app-server daemon start and codex app-server daemon version, or just codex. → expect: the daemon starts and Codex opens. Two commenters confirmed this, on 0.160.0 and on 0.162.0. Our inference: if you set CODEX_HOME, use that folder instead of $HOME\.codex.
5. If you need the old behaviour with the shared server and none of the above works, pin the last version that worked for most commenters: npm install -g @openai/codex@0.156.1. → expect: codex starts normally (confirmed by many commenters on Windows; one reported that rolling back did not help after 0.159.3, so treat it as a fallback).

How to verify

Run codex (or codex --no-daemon if you chose step 1 or 2) and send a short prompt → expect: a normal reply with no daemon error.

What did not work

Upgrading to 0.158.0 did not fix it for several commenters. Reinstalling the CLI or using a fresh CODEX_HOME did not help one commenter with the installer variant.

Rollback

Remove daemon_auto_start = false from config.toml, rename the backed-up app-server-control and app-server-daemon folders back, or reinstall the latest version with npm install -g @openai/codex.

Risks

Without the daemon you lose shared-server features such as background work that continues after the CLI exits and the cross-session view (a Codex contributor), and one commenter found it slower. Version 0.156.1 lacks newer fixes and features. Do not kill the process that owns the stale daemon process ID: in one report it was Windows Defender. Don't run Codex as administrator or turn UAC off to work around this, and don't loosen permissions on the .codex folder (our inference: elevated sessions are exactly what the check blocks, and wider folder permissions let other users change the daemon files).

Verified scope

Codex CLI 0.157.0 to at least 0.162.1 on Windows, Sep–Oct 2026.

Becomes obsolete when

A Codex CLI release notes a fix for the Windows Access is denied daemon errors, and elevated terminals either use the shared server or fall back with a clear notice (one commenter already saw such a notice on 0.162.1; see environment).