Summary
A standalone Windows desktop helper invokes the bundled Codex CLI for a separate, read-only conversation. It fails before receiving any model reply:
Error: failed to initialize in-process app-server client: Access is denied. (os error 5)
Environment and scope
codex-cli 0.160.0, bundled with the Windows Codex desktop app.- Child process started by Python with argument-list invocation, piped stdin/stdout/stderr and
CREATE_NO_WINDOW.
- These diagnostic runs were launched through a Codex tool execution environment. Reproduction in an ordinary user terminal outside that environment has NOT been established, so nested sandbox/IPC restrictions remain a possible explanation.
- Existing ChatGPT sign-in is detected by
codex login status with the normal user CODEX_HOME explicitly set. No credentials were copied.
Command shape (personal paths redacted)
codex --no-daemon -c sqlite_home="<helper>/runtime-state" -c log_dir="<helper>/runtime-state/logs" exec --ephemeral --json --sandbox read-only --skip-git-repo-check -C "<helper>" -
Input was a trivial connection-test greeting, with no attachments.
Observed tests
- Same initialization error with and without
--no-daemon.
- Workspace-local SQLite/log paths allow runtime database creation but do not resolve startup.
- Explicit filesystem permission grants for the user Codex runtime directory did not resolve the earlier tests.
- A documented stdio app-server initialization test also returned Access denied before an initialize response.
- Latest run additionally warned about access denied cleaning/creating
<CODEX_HOME>/tmp/arg0 entries.
- No sandbox bypass, administrator elevation or security-setting changes were attempted.
Request for guidance
What supported diagnostic can identify the specific denied path or IPC operation behind this in-process initialization error? Is this expected when launching a separate read-only CLI client from within a Codex tool environment, and what is the supported launch approach for an independent desktop client?
Related reports: #51339, #49449, #50608. Those discuss daemon installation/startup; a shared root cause is unconfirmed here because this failure names the in-process app-server client and persists with --no-daemon.
The helper is intended to make text and screenshot sharing easier from an always-on-top window. A supported solution that retains read-only sandboxing would be especially useful.
Summary
A standalone Windows desktop helper invokes the bundled Codex CLI for a separate, read-only conversation. It fails before receiving any model reply:
Environment and scope
codex-cli 0.160.0, bundled with the Windows Codex desktop app.CREATE_NO_WINDOW.codex login statuswith the normal user CODEX_HOME explicitly set. No credentials were copied.Command shape (personal paths redacted)
Input was a trivial connection-test greeting, with no attachments.
Observed tests
--no-daemon.<CODEX_HOME>/tmp/arg0entries.Request for guidance
What supported diagnostic can identify the specific denied path or IPC operation behind this in-process initialization error? Is this expected when launching a separate read-only CLI client from within a Codex tool environment, and what is the supported launch approach for an independent desktop client?
Related reports: #51339, #49449, #50608. Those discuss daemon installation/startup; a shared root cause is unconfirmed here because this failure names the in-process app-server client and persists with
--no-daemon.The helper is intended to make text and screenshot sharing easier from an always-on-top window. A supported solution that retains read-only sandboxing would be especially useful.