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.
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.
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.
Which means your local Git pipelines, your Node scripts, basically anything that
relies on the CLI containerizing your shell executions, just dies.
But 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.
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.
Or, 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.
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.
Yes!
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.
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.
Which is exactly where the new codex doctor updates come in.
In the past, running codex doctor was...
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.
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.
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.
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.
Oh, I ran into this last week.
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."
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.
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.
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.
See ya!