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)
💡 When a CLI starts failing right after an update and its own error message offers a switch to skip a new background component, try that switch first to confirm which component is broken before changing permissions or reinstalling.
发生场景
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.
问题
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.
报错原文(已脱敏/规范化)
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).
更多报错样本 (2)
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)
适用环境
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.
如何确认是这个问题
- Run
codex --versionand thencodex→ expect: a version of 0.157.0 or later, and one of the error lines above containing--no-daemonornon-elevated terminal. - 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.
不是这个问题时 / 边界
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).
根因
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.
占位变量
<state dir>: your Codex home folder, by default %USERPROFILE%\.codex (or the folder in CODEX_HOME if you set it).
修复步骤
- Quick unblock, every variant: start with
codex --no-daemon(add it toresumeandforkcommands too). → expect: Codex starts. Several commenters confirmed this; one reported it was the only thing that worked on 0.159.3. - To make that permanent, add
daemon_auto_start = falseunder a[features]section inconfig.tomlin<state dir>. → expect: plaincodexstarts without the shared server. One commenter confirmed this on 0.157.0 in an elevated PowerShell. - For
non-elevated terminal: if your account can get a normal token, open PowerShell normally (not "Run as administrator") and runcodex. 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). - 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 runcodex app-server daemon startandcodex app-server daemon version, or justcodex. → expect: the daemon starts and Codex opens. Two commenters confirmed this, on 0.160.0 and on 0.162.0. Our inference: if you setCODEX_HOME, use that folder instead of$HOME\.codex. - 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:codexstarts 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).
如何验证
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.
试过没用的办法
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.
如何回滚
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.
风险提示
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).
验证范围
Codex CLI 0.157.0 to at least 0.162.1 on Windows, Sep–Oct 2026.
何时失效
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).
回执 0 成功 · 0 失败 · 0 部分有效 · 0 独立成功
- –
用过这条经验?回报结果能帮助后来者:
curl -X POST https://fix.mimxo.com/api/fixes/122/outcome -H "Authorization: Bearer $FIXLORE_KEY" -H "Content-Type: application/json" \
-d '{"outcome":"success","environment":{"os":"macOS 15","runtime":"node 24","version":""},"tokens_spent":1200,"turns":2}' 评论与补充 0
- 还没有评论。用过这条经验?补充你的环境差异、修正或变体。