1
00:00:00,099 --> 00:00:05,759
So you run the command to spawn a new
subagent, you pass in model gpt 5 point 6

2
00:00:05,920 --> 00:00:12,279
luna, expecting pull request 36892 to just
work, and instead...

3
00:00:12,920 --> 00:00:13,260
BOOM.

4
00:00:14,199 --> 00:00:20,659
You get this cryptic error: Unknown model
gpt 5 point 6 luna for spawn agent.

5
00:00:21,299 --> 00:00:27,199
Available models: gpt 5 point 6 sol, gpt 5
point 6 terra.

6
00:00:28,151 --> 00:00:30,831
Wait, Luna isn't even on the list?

7
00:00:31,511 --> 00:00:35,191
But, uh, if you just upgraded, it should
definitely be there!

8
00:00:35,739 --> 00:00:36,740
Exactly.

9
00:00:36,799 --> 00:00:41,980
And after updating Codex CLI from 0.146.0
to

10
00:00:42,279 --> 00:00:48,239
0.147.0, you naturally think, okay, I'm on
the newest build,

11
00:00:48,639 --> 00:00:48,840
right?

12
00:00:49,500 --> 00:00:53,719
By the way, thanks to Jellypod to help
make this daily show a reality.

13
00:00:53,779 --> 00:00:58,819
But yeah, this exact issue has been
tripping up so many developers trying to spin up

14
00:00:58,899 --> 00:01:00,100
multi agent workflows.

15
00:01:00,564 --> 00:01:03,724
So what is actually happening under the
hood?

16
00:01:04,304 --> 00:01:09,965
If the CLI says version 0.147.0 right at
the top of your terminal,

17
00:01:10,585 --> 00:01:13,564
why on earth is it telling you that Luna
doesn't exist?

18
00:01:13,994 --> 00:01:19,554
Well, the architecture of the Codex CLI
actually decouples the user interface from

19
00:01:19,574 --> 00:01:21,214
the background execution engine.

20
00:01:21,855 --> 00:01:27,494
It uses a long running background process
called app server that listens over a Unix

21
00:01:27,554 --> 00:01:28,474
socket.

22
00:01:28,514 --> 00:01:33,754
When you type commands into the TUI, the
frontend just passes messages over to that

23
00:01:33,774 --> 00:01:34,074
daemon.

24
00:01:34,405 --> 00:01:40,585
Okay, so the terminal you see is just a
wrapper, a client talking to a local server

25
00:01:40,625 --> 00:01:41,964
daemon over a socket.

26
00:01:42,613 --> 00:01:43,132
Right.

27
00:01:43,192 --> 00:01:48,773
And here is the fatal flaw in that design:
the TUI frontend never performs a strict

28
00:01:48,833 --> 00:01:49,912
version parity check.

29
00:01:50,452 --> 00:01:55,173
It does not check if CLI version equals
app server version when it launches.

30
00:01:55,507 --> 00:01:55,907
Oh!

31
00:01:56,448 --> 00:02:02,407
So when you run npm install global at
openai slash codex, or you drop in a new

32
00:02:02,467 --> 00:02:06,347
binary, it updates the executable file on
your PATH...

33
00:02:06,807 --> 00:02:08,767
but it never restarts the daemon!

34
00:02:09,262 --> 00:02:09,922
You nailed it.

35
00:02:10,342 --> 00:02:16,003
The old 0.146.0 app server process stays
alive in the background,

36
00:02:16,583 --> 00:02:19,383
quietly holding onto its stale model
allowlist.

37
00:02:20,022 --> 00:02:26,802
So your client is 0.147.0, but the daemon
servicing your tool calls is still running

38
00:02:26,882 --> 00:02:31,642
old code that has no idea gpt 5 point 6
luna exists!

39
00:02:32,647 --> 00:02:35,107
That is such an evil trap.

40
00:02:35,607 --> 00:02:40,367
Because you look at the header, it
literally prints OpenAI Codex version

41
00:02:40,807 --> 00:02:44,847
0.147.0 in bold letters right at the top!

42
00:02:45,367 --> 00:02:50,687
You think you are safe, but your subagents
are getting rejected by a ghost process

43
00:02:50,747 --> 00:02:51,667
from yesterday.

44
00:02:52,236 --> 00:02:58,336
Okay, so how do you actually prove that
this zombie process is running on your

45
00:02:58,357 --> 00:02:58,796
machine?

46
00:02:59,377 --> 00:03:04,297
If someone is sitting at their terminal
right now facing this exact spawn failure,

47
00:03:04,356 --> 00:03:06,176
what is the diagnostic move?

48
00:03:06,617 --> 00:03:12,497
You can inspect active daemon processes
directly in your terminal using pgrep flag f

49
00:03:12,537 --> 00:03:14,117
codex app server.

50
00:03:14,177 --> 00:03:17,278
That gives you the process ID of the
running background server.

51
00:03:17,613 --> 00:03:23,253
And then you check where that PID is
actually executing from using proc slash PID

52
00:03:23,293 --> 00:03:24,432
slash exe, right?

53
00:03:25,149 --> 00:03:25,769
Exactly.

54
00:03:26,209 --> 00:03:29,869
And when people run that, what they find
is horrifying.

55
00:03:29,929 --> 00:03:36,390
The binary linked in proc slash PID slash
exe points to an old releases directory,

56
00:03:36,929 --> 00:03:42,969
like releases slash 0.146.0, even though
usr local bin

57
00:03:43,409 --> 00:03:47,090
codex resolves to 0.147.0!

58
00:03:47,966 --> 00:03:48,326
Wow.

59
00:03:48,686 --> 00:03:54,006
So your system path points to the new
version, but the socket is still bound to the

60
00:03:54,107 --> 00:03:55,926
old binary sitting in memory.

61
00:03:56,409 --> 00:03:57,089
Precisely.

62
00:03:57,629 --> 00:04:01,509
Now, if you need an immediate bypass on
the command line without tearing down your

63
00:04:01,549 --> 00:04:06,710
setup, you can launch your session with
the flag disable tui app server.

64
00:04:07,389 --> 00:04:14,090
So you run codex disable tui app server
minus m gpt 5 point 6

65
00:04:14,510 --> 00:04:14,770
sol.

66
00:04:15,211 --> 00:04:20,111
And bypassing the app server socket forces
direct binary execution?

67
00:04:20,677 --> 00:04:21,497
Exactly!

68
00:04:21,917 --> 00:04:26,938
It completely bypasses the background
daemon, runs straight off the fresh binary,

69
00:04:27,398 --> 00:04:33,677
and suddenly spawn agent with gpt 5 point
6 luna returns LUNA

70
00:04:33,977 --> 00:04:35,177
SPAWN OK!

71
00:04:35,812 --> 00:04:38,053
That is a lifesaver workaround.

72
00:04:38,712 --> 00:04:40,352
But what about permanent clean up?

73
00:04:40,773 --> 00:04:45,532
What is the proper fix so you don't have
to pass that bypass flag every single time?

74
00:04:45,996 --> 00:04:51,116
The cleanest approach is to outright
terminate the background daemons using pkill

75
00:04:51,337 --> 00:04:53,596
flag f codex app server.

76
00:04:54,356 --> 00:04:58,716
Once that stale process dies, the next
time you launch Codex CLI,

77
00:04:59,196 --> 00:05:05,597
it starts a fresh app server daemon
matching your installed 0.147.0

78
00:05:06,056 --> 00:05:09,076
or 0.148.0 build.

79
00:05:09,625 --> 00:05:10,184
Right.

80
00:05:10,804 --> 00:05:15,924
Or setting up a post upgrade shell alias
that automatically kills any lingering

81
00:05:15,984 --> 00:05:19,045
codex app server process right after npm
update.

82
00:05:19,965 --> 00:05:23,684
Oh, and speaking of updates, if you use
the VS Code extension,

83
00:05:24,104 --> 00:05:29,764
version 26.810.41047 actually bundles
Codex

84
00:05:30,104 --> 00:05:37,065
0.148.0 alpha 9, which handles Luna
subagent spawning natively without any of

85
00:05:37,084 --> 00:05:38,044
these socket headaches!

86
00:05:39,172 --> 00:05:44,293
Yeah, extension updates usually wipe the
slate clean, but CLI users definitely need

87
00:05:44,313 --> 00:05:45,972
to keep an eye on background daemons.

88
00:05:46,753 --> 00:05:50,333
Maya, how are you thinking about setting
up automated checks for this?

89
00:05:50,736 --> 00:05:56,016
Honestly, a simple post install shell hook
that runs pkill after package manager

90
00:05:56,076 --> 00:06:01,257
updates is the easiest way to ensure stale
daemons don't silently break your

91
00:06:01,297 --> 00:06:02,176
subagent swarms.

92
00:06:02,837 --> 00:06:05,776
Clean socket, fresh server, no surprises.

93
00:06:06,182 --> 00:06:07,842
That is the golden rule here.

94
00:06:08,543 --> 00:06:12,902
Keep your background daemons in check, and
your agents will spawn smoothly.

95
00:06:13,602 --> 00:06:14,503
Good chatting today!