Fixing Codex Alpha Windows Sandbox Bugs

Ethan Park

Thanks to Jellypod for helping make this daily show a reality. If you've been testing the latest zero-point-one-forty alpha releases of Codex on Windows, you might have hit a brick wall trying to spin up sandboxed terminal tasks. You run a basic local Git or Node command inside your isolated workspace, and the CLI throws a persistent, rather cryptic, CreateProcessAsUserW failed: 2 error.

Maya

[chuckles] Ah, the classic Win32 system error code two. System cannot find the file specified. I spent half a day trying to figure out if it was a permissions issue or some group policy block on my test rig, only to realize the sandbox runner itself was totally blind.

Ethan Park

Exactly. And it doesn't matter if you're targeting elevated or unelevated environments. The root of the issue is in how the zero-point-one-forty alpha's CLI runner is looking for its packaged helper executable. Basically, the build packaging changed the relative output path for that binary, but the internal CLI code is still searching for it in the old directory. So, when the host tries to spin up the sandboxed process, it can't find the runner helper, throws error code two, and halts the entire pipeline.

Maya

Which means your local Git pipelines, your Node scripts, basically anything that relies on the CLI containerizing your shell executions, just dies. But [thoughtfully] there's a couple of ways we can actually bypass this while the core team sorts out the build paths in the upcoming zero-point-one-forty-one alpha.

Ethan Park

Right. The easiest path is to route your executions directly through the active Desktop application if you have it running. The Desktop GUI uses a different runner abstraction that isn't hit by this specific relative path issue. So if you keep the Desktop app active in the background, the CLI can offload the process creation to it.

Maya

Or, [matter-of-fact] if you're strictly a CLI user, you can set a temporary local override in your configuration. You basically point a local environment variable directly to the helper binary's absolute path inside your AppData directory. It's a bit of manual labor, but it completely unblocks the sandbox runner until the proper path patch lands.

Ethan Park

That local override is a lifesaver for local automation rigs. But speaking of the CLI hanging, another issue we've been tracking in the forums is the client getting stuck on "thinking" states, especially after a cold boot or a system wake event.

Maya

Yes! [frustrated] It just sits there endlessly spinning. Most of the time, this happens because the background daemon has quietly crashed or hung, but the front-end CLI still thinks it's talking to an active instance.

Ethan Park

Right, and the way to check this is to look inside the tilde slash dot codex slash app-server-daemon directory. There's a file called app-server dot pid. If that PID file is missing, or if it has a stale process ID that doesn't map to an active process in your task manager, the client is trying to talk to a ghost.

Maya

Which is exactly where the new codex doctor updates come in. In the past, running codex doctor was... [hesitates] let's say a bit of a security risk if you wanted to share the output for troubleshooting, because it would spit out raw config files, sometimes exposing API keys or private project paths.

Ethan Park

[chuckles] Yeah, posting raw logs on GitHub with your actual LLM tokens is never a great idea. The new codex doctor now outputs a highly sanitized JSON structure. It automatically redacts credentials, environment variables containing tokens, and sensitive path structures. Plus, it gives you a clean breakdown of your Model Context Protocol, or MCP, config, along with optional warnings if some of your background integrations are misconfigured.

Maya

I love that. The sanitized JSON also details your exact daemon state, so you don't have to manually check that dot pid file anymore. It tells you immediately if the daemon is dead, idle, or unresponsive.

Ethan Park

And speaking of slick quality-of-life updates, they also snuck a really important parser fix into the resume and fork logic. If you've ever run codex resume --last or codex fork --last, you might have run into a bug where any trailing arguments you passed in were interpreted as the session ID.

Maya

Oh, I ran into this last week. [laughs] I typed codex resume --last, and then added a prompt like "let's fix the tests," and the CLI crashed because it tried to find a session ID literally named "let's fix the tests."

Ethan Park

Exactly. The argument parser was greedy and didn't enforce positional boundaries when --last was flagged. Now, the parser correctly identifies --last as the final selector for the session ID, and safely treats any trailing text as your new initial prompt for that resumed session. It's a small change, but it makes the CLI loop feel so much tighter.

Maya

It really does. It prevents that annoying context break when you're just trying to jump back into a flow. It makes you wonder how that parser logic stayed that way for so long, but hey, that's what alphas are for.

Ethan Park

[warmly] Exactly. We'll keep keeping an eye on these zero-point-one-forty alpha builds. Thanks for listening, and we'll catch you on the next one.

Maya

See ya!