1
00:00:00,280 --> 00:00:04,460
Quick thanks to Jellypod for helping make
this daily show a reality.

2
00:00:05,380 --> 00:00:09,920
Last time we told you to restart your
background daemon after changing config in

3
00:00:10,140 --> 00:00:11,940
0.163.0.

4
00:00:12,780 --> 00:00:14,220
Today is the flip side of that.

5
00:00:14,900 --> 00:00:19,600
A daemon that looks alive, accepts
connections, and still never answers the one

6
00:00:19,660 --> 00:00:21,060
request your session needs.

7
00:00:21,807 --> 00:00:25,467
The symptom is a CLI session stuck on
"Waiting for startup,"

8
00:00:25,547 --> 00:00:26,747
with no error at all.

9
00:00:27,227 --> 00:00:31,727
It comes from GitHub issue 55000, filed
October 18, 2026.

10
00:00:32,287 --> 00:00:34,567
The reporter first saw it in a shared
daemon session.

11
00:00:35,067 --> 00:00:40,207
Then they reproduced it on macOS arm64
with a freshly launched app server reporting

12
00:00:40,487 --> 00:00:46,327
0.163.0, using an isolated temporary
CODEX_HOME, no copied credentials,

13
00:00:46,427 --> 00:00:47,447
and no inference request.

14
00:00:47,927 --> 00:00:50,387
So this is a controlled repro, not just a
hunch.

15
00:00:51,108 --> 00:00:51,908
Here's the path.

16
00:00:52,508 --> 00:00:56,248
At startup the client sends an
account/read request.

17
00:00:56,888 --> 00:01:03,728
That calls read_account, which reloads
configuration through load_latest_config with

18
00:01:03,788 --> 00:01:04,347
no project.

19
00:01:05,407 --> 00:01:10,848
0.163.0 changed that reload to use a non
project configuration with a stable Codex

20
00:01:10,908 --> 00:01:13,188
home fallback, so the general case was
fixed.

21
00:01:13,988 --> 00:01:18,148
An earlier issue, 54408, was closed on
that basis.

22
00:01:18,828 --> 00:01:19,928
But there's a leftover.

23
00:01:20,848 --> 00:01:25,748
Each command backed provider auth table
has a cwd field, and when you omit it,

24
00:01:26,128 --> 00:01:29,708
a function called
default_provider_auth_cwd fills it in.

25
00:01:30,508 --> 00:01:33,088
That function falls back to the process's
current directory,

26
00:01:33,448 --> 00:01:35,428
and if it can't get one, it panics.

27
00:01:36,088 --> 00:01:41,448
The exact message is: provider auth cwd
must resolve, no such file or directory,

28
00:01:41,848 --> 00:01:42,688
os error 2.

29
00:01:43,257 --> 00:01:47,837
And the part that makes this nasty is that
the provider doesn't have to be in use.

30
00:01:48,437 --> 00:01:52,797
The reporter's config had a provider
called repro, with a base URL and an auth table

31
00:01:52,817 --> 00:01:54,297
containing just a command.

32
00:01:55,057 --> 00:01:57,857
No model_provider line selecting it.

33
00:01:58,437 --> 00:02:00,657
The default OpenAI provider stayed
selected.

34
00:02:01,117 --> 00:02:02,237
They ran three controls.

35
00:02:02,637 --> 00:02:07,077
With no provider definition, account/read
worked before and after deleting the

36
00:02:07,137 --> 00:02:08,517
server's startup directory.

37
00:02:09,277 --> 00:02:13,837
With the unused provider and no auth cwd,
it worked before deletion,

38
00:02:14,177 --> 00:02:17,397
then after deletion got no response within
five seconds.

39
00:02:18,057 --> 00:02:23,677
Same provider with cwd set to slash in its
auth table, it worked both times.

40
00:02:24,543 --> 00:02:29,603
So the failure happens when the config is
deserialized, before any question of which

41
00:02:29,643 --> 00:02:30,523
provider you're using.

42
00:02:31,983 --> 00:02:33,803
One detail worth being precise about.

43
00:02:34,463 --> 00:02:36,223
The server process stayed alive.

44
00:02:36,983 --> 00:02:41,463
The request just never got a response, and
stderr showed the panic at

45
00:02:41,543 --> 00:02:44,983
config_types.rs, line 629.

46
00:02:46,143 --> 00:02:49,743
That would explain why the client has
nothing to show you, though the report doesn't

47
00:02:49,823 --> 00:02:53,963
spell out how the dropped request turns
into a hang, so treat that last step as our

48
00:02:54,003 --> 00:02:54,303
reading.

49
00:02:55,043 --> 00:02:58,823
Also, the reporter deleted an empty
temporary startup directory.

50
00:02:59,643 --> 00:03:02,723
If your daemon was launched from a scratch
folder you later cleaned up,

51
00:03:03,263 --> 00:03:06,883
that's the same shape, but that's our
inference, not something the issue claims.

52
00:03:07,477 --> 00:03:08,397
So what do you do today.

53
00:03:09,097 --> 00:03:14,397
First, check your config.toml for any
model providers entry that has an auth table

54
00:03:14,437 --> 00:03:18,397
with a command, and add an explicit cwd to
each one.

55
00:03:18,997 --> 00:03:22,117
The reporter's test used slash, and that
restored success.

56
00:03:22,737 --> 00:03:25,937
But they also note that the right
directory depends on what your auth command

57
00:03:26,037 --> 00:03:29,617
actually needs, so pick something durable
that makes sense for your helper.

58
00:03:30,137 --> 00:03:32,857
A stable path under your Codex home is a
reasonable shape.

59
00:03:33,917 --> 00:03:38,217
If you're already hung, the reporter's
recovery was to run codex with the no daemon

60
00:03:38,277 --> 00:03:42,237
flag, or to stop the daemon and start a
new session from a directory that still

61
00:03:42,297 --> 00:03:42,797
exists.

62
00:03:43,637 --> 00:03:47,037
And since a running daemon only loads
config when it deserializes it,

63
00:03:47,417 --> 00:03:50,077
remember our restart advice from last time
after you edit.

64
00:03:50,930 --> 00:03:51,430
Caveats.

65
00:03:52,090 --> 00:03:57,130
As of the report, the issue is open,
labeled a bug, with nobody assigned,

66
00:03:57,710 --> 00:04:01,170
and it's one reporter's reproduction,
repeated in a second run.

67
00:04:02,170 --> 00:04:07,710
The expected behavior they describe is
that an omitted auth cwd should resolve

68
00:04:07,770 --> 00:04:11,310
against a valid base or return a handled
error, not panic.

69
00:04:12,110 --> 00:04:16,850
So an explicit cwd is a workaround, not a
confirmed permanent answer.

70
00:04:17,609 --> 00:04:21,450
Also, the no daemon flag only gets you out
of this particular trap.

71
00:04:21,910 --> 00:04:23,510
It doesn't change what's in your config.

72
00:04:24,225 --> 00:04:25,765
A few smaller things from this week.

73
00:04:26,285 --> 00:04:33,145
Issue 54816 reports that in 0.164.0 alpha
3, which is a

74
00:04:33,185 --> 00:04:37,045
prerelease, typing right after launch can
stall echo and redraw.

75
00:04:37,705 --> 00:04:42,325
Session attachment triggers a second
skills refresh, and the main event loop awaits

76
00:04:42,385 --> 00:04:45,665
that request inline, so terminal input
waits for it.

77
00:04:46,245 --> 00:04:49,885
The reporter delayed that response six
seconds on purpose to expose it,

78
00:04:49,985 --> 00:04:52,525
so don't read six seconds as a normal
delay.

79
00:04:53,345 --> 00:04:58,085
Next, issue 54738, on WSL2 with

80
00:04:58,545 --> 00:05:05,105
0.163.0: resuming with the no daemon flag
can show "This conversation is open in

81
00:05:05,145 --> 00:05:10,145
another app," when the owner is actually
Codex's own shared daemon holding an idle

82
00:05:10,165 --> 00:05:10,745
writer lock.

83
00:05:11,365 --> 00:05:15,965
The reporter's workaround was codex no
daemon fork with the thread ID,

84
00:05:16,345 --> 00:05:19,185
which continues in a new thread rather
than restoring the original.

85
00:05:19,865 --> 00:05:26,605
And one genuine improvement in the 0.163.0
notes: you can return to an existing

86
00:05:26,705 --> 00:05:31,985
side conversation with /side after
switching threads, and answers to pending prompts

87
00:05:32,025 --> 00:05:33,505
go back to the thread that asked.

88
00:05:34,367 --> 00:05:40,087
If you only do one thing after this
episode, open your config and look for provider

89
00:05:40,107 --> 00:05:42,347
auth tables without a cwd.

90
00:05:43,007 --> 00:05:47,767
It takes a minute, and it's the difference
between a clear error and a session that

91
00:05:47,847 --> 00:05:49,047
just sits there waiting.