1
00:00:00,000 --> 00:00:03,520
Thanks to Jellypod for helping make this
daily show a reality.

2
00:00:03,733 --> 00:00:08,240
If you've been testing the latest
zero-point-one-forty alpha releases of Codex on

3
00:00:08,310 --> 00:00:13,600
Windows, you might have hit a brick wall
trying to spin up sandboxed terminal tasks.

4
00:00:13,760 --> 00:00:18,880
You run a basic local Git or Node command
inside your isolated workspace,

5
00:00:18,920 --> 00:00:25,680
and the CLI throws a persistent, rather
cryptic, CreateProcessAsUserW failed: 2

6
00:00:25,773 --> 00:00:26,400
error.

7
00:00:28,519 --> 00:00:32,799
Ah, the classic Win32 system error code
two.

8
00:00:33,239 --> 00:00:35,519
System cannot find the file specified.

9
00:00:36,139 --> 00:00:41,819
I spent half a day trying to figure out if
it was a permissions issue or some group

10
00:00:41,939 --> 00:00:47,879
policy block on my test rig, only to
realize the sandbox runner itself was totally

11
00:00:48,000 --> 00:00:48,559
blind.

12
00:00:49,000 --> 00:00:50,000
Exactly.

13
00:00:50,070 --> 00:00:54,760
And it doesn't matter if you're targeting
elevated or unelevated environments.

14
00:00:54,780 --> 00:01:00,360
The root of the issue is in how the
zero-point-one-forty alpha's CLI runner is

15
00:01:00,420 --> 00:01:03,000
looking for its packaged helper
executable.

16
00:01:03,112 --> 00:01:08,440
Basically, the build packaging changed the
relative output path for that binary,

17
00:01:08,460 --> 00:01:12,840
but the internal CLI code is still
searching for it in the old directory.

18
00:01:12,893 --> 00:01:17,480
So, when the host tries to spin up the
sandboxed process, it can't find the runner

19
00:01:17,537 --> 00:01:22,360
helper, throws error code two, and halts
the entire pipeline.

20
00:01:23,420 --> 00:01:28,699
Which means your local Git pipelines, your
Node scripts, basically anything that

21
00:01:28,739 --> 00:01:33,420
relies on the CLI containerizing your
shell executions, just dies.

22
00:01:34,279 --> 00:01:39,779
But there's a couple of ways we can
actually bypass this while the core team sorts

23
00:01:39,819 --> 00:01:43,260
out the build paths in the upcoming
zero-point-one-forty-one alpha.

24
00:01:44,000 --> 00:01:44,800
Right.

25
00:01:44,840 --> 00:01:49,520
The easiest path is to route your
executions directly through the active Desktop

26
00:01:49,587 --> 00:01:51,960
application if you have it running.

27
00:01:52,050 --> 00:01:57,040
The Desktop GUI uses a different runner
abstraction that isn't hit by this specific

28
00:01:57,084 --> 00:01:58,160
relative path issue.

29
00:01:58,373 --> 00:02:03,760
So if you keep the Desktop app active in
the background, the CLI can offload the

30
00:02:03,830 --> 00:02:05,280
process creation to it.

31
00:02:06,340 --> 00:02:11,679
Or, if you're strictly a CLI user, you can
set a temporary local override in your

32
00:02:11,719 --> 00:02:12,519
configuration.

33
00:02:13,000 --> 00:02:17,439
You basically point a local environment
variable directly to the helper binary's

34
00:02:17,539 --> 00:02:20,259
absolute path inside your AppData
directory.

35
00:02:20,779 --> 00:02:25,419
It's a bit of manual labor, but it
completely unblocks the sandbox runner until the

36
00:02:25,479 --> 00:02:26,799
proper path patch lands.

37
00:02:28,000 --> 00:02:32,320
That local override is a lifesaver for
local automation rigs.

38
00:02:32,460 --> 00:02:37,840
But speaking of the CLI hanging, another
issue we've been tracking in the forums is

39
00:02:37,860 --> 00:02:43,120
the client getting stuck on "thinking"
states, especially after a cold boot or a

40
00:02:43,189 --> 00:02:44,400
system wake event.

41
00:02:45,560 --> 00:02:46,139
Yes!

42
00:02:46,599 --> 00:02:48,939
It just sits there endlessly spinning.

43
00:02:49,719 --> 00:02:54,039
Most of the time, this happens because the
background daemon has quietly crashed or

44
00:02:54,099 --> 00:02:58,519
hung, but the front-end CLI still thinks
it's talking to an active instance.

45
00:02:59,000 --> 00:03:04,520
Right, and the way to check this is to
look inside the tilde slash dot codex slash

46
00:03:04,600 --> 00:03:06,120
app-server-daemon directory.

47
00:03:06,213 --> 00:03:09,960
There's a file called app-server dot pid.

48
00:03:10,200 --> 00:03:16,200
If that PID file is missing, or if it has
a stale process ID that doesn't map to an

49
00:03:16,269 --> 00:03:20,920
active process in your task manager, the
client is trying to talk to a ghost.

50
00:03:21,419 --> 00:03:25,119
Which is exactly where the new codex
doctor updates come in.

51
00:03:25,639 --> 00:03:28,519
In the past, running codex doctor was...

52
00:03:29,039 --> 00:03:33,000
let's say a bit of a security risk if you
wanted to share the output for

53
00:03:33,119 --> 00:03:36,679
troubleshooting, because it would spit out
raw config files,

54
00:03:37,139 --> 00:03:40,619
sometimes exposing API keys or private
project paths.

55
00:03:41,571 --> 00:03:47,880
Yeah, posting raw logs on GitHub with your
actual LLM tokens is never a great idea.

56
00:03:47,980 --> 00:03:52,440
The new codex doctor now outputs a highly
sanitized JSON structure.

57
00:03:52,653 --> 00:03:57,880
It automatically redacts credentials,
environment variables containing tokens,

58
00:03:57,920 --> 00:03:59,560
and sensitive path structures.

59
00:03:59,736 --> 00:04:04,200
Plus, it gives you a clean breakdown of
your Model Context Protocol,

60
00:04:04,253 --> 00:04:10,040
or MCP, config, along with optional
warnings if some of your background integrations

61
00:04:10,100 --> 00:04:11,160
are misconfigured.

62
00:04:12,720 --> 00:04:13,399
I love that.

63
00:04:13,819 --> 00:04:18,599
The sanitized JSON also details your exact
daemon state, so you don't have to

64
00:04:18,719 --> 00:04:21,000
manually check that dot pid file anymore.

65
00:04:21,399 --> 00:04:25,579
It tells you immediately if the daemon is
dead, idle, or unresponsive.

66
00:04:26,000 --> 00:04:31,120
And speaking of slick quality-of-life
updates, they also snuck a really important

67
00:04:31,189 --> 00:04:34,080
parser fix into the resume and fork logic.

68
00:04:34,293 --> 00:04:40,800
If you've ever run codex resume --last or
codex fork --last,

69
00:04:40,840 --> 00:04:45,120
you might have run into a bug where any
trailing arguments you passed in were

70
00:04:45,173 --> 00:04:47,200
interpreted as the session ID.

71
00:04:48,479 --> 00:04:50,839
Oh, I ran into this last week.

72
00:04:51,699 --> 00:04:57,180
I typed codex resume --last, and then
added a prompt like "let's fix the tests,"

73
00:04:57,619 --> 00:05:03,179
and the CLI crashed because it tried to
find a session ID literally named "let's fix

74
00:05:03,219 --> 00:05:03,800
the tests."

75
00:05:05,000 --> 00:05:05,920
Exactly.

76
00:05:05,990 --> 00:05:10,920
The argument parser was greedy and didn't
enforce positional boundaries when --last

77
00:05:10,960 --> 00:05:11,640
was flagged.

78
00:05:11,800 --> 00:05:16,840
Now, the parser correctly identifies
--last as the final selector for the session

79
00:05:16,973 --> 00:05:22,680
ID, and safely treats any trailing text as
your new initial prompt for that resumed

80
00:05:22,740 --> 00:05:23,560
session.

81
00:05:23,693 --> 00:05:28,040
It's a small change, but it makes the CLI
loop feel so much tighter.

82
00:05:29,379 --> 00:05:30,439
It really does.

83
00:05:30,779 --> 00:05:35,239
It prevents that annoying context break
when you're just trying to jump back into a

84
00:05:35,279 --> 00:05:35,599
flow.

85
00:05:36,199 --> 00:05:39,599
It makes you wonder how that parser logic
stayed that way for so long,

86
00:05:39,760 --> 00:05:41,599
but hey, that's what alphas are for.

87
00:05:42,170 --> 00:05:43,040
Exactly.

88
00:05:43,120 --> 00:05:47,120
We'll keep keeping an eye on these
zero-point-one-forty alpha builds.

89
00:05:47,177 --> 00:05:49,760
Thanks for listening, and we'll catch you
on the next one.

90
00:05:50,399 --> 00:05:50,839
See ya!