1
00:00:00,280 --> 00:00:05,640
Hey, it's another day in Codex land, and
thanks to Jellypod for helping make this

2
00:00:05,680 --> 00:00:07,040
daily show a reality.

3
00:00:08,460 --> 00:00:13,360
Last episode we mentioned the new resume
flag on codex queue almost in passing.

4
00:00:14,480 --> 00:00:19,660
Today we're drilling into why it exists,
because it's tied to a default that changed

5
00:00:19,720 --> 00:00:24,880
in the same release, 0.166.0, which
shipped October 29.

6
00:00:25,780 --> 00:00:27,020
Start with the old behavior.

7
00:00:27,520 --> 00:00:32,380
Codex queue talks to the app server and
sends thread/queue/add.

8
00:00:33,060 --> 00:00:36,380
That persists your message, and that's all
it does.

9
00:00:36,740 --> 00:00:37,960
It doesn't wake the thread.

10
00:00:38,700 --> 00:00:42,380
GitHub issue 44491 documented the result.

11
00:00:43,060 --> 00:00:46,680
Someone queued a message to a saved thread
that had unloaded,

12
00:00:47,260 --> 00:00:52,220
the command succeeded, and the input sat
pending for hours until another client

13
00:00:52,280 --> 00:00:53,760
called thread/resume.

14
00:00:54,520 --> 00:00:58,300
The maintainer, etraut, closed it as not
planned.

15
00:00:58,840 --> 00:01:02,680
He said queue intentionally persists input
without resuming,

16
00:01:03,180 --> 00:01:07,300
and suggested a wrapper script that runs
codex queue and then codex resume.

17
00:01:07,840 --> 00:01:09,960
And here's the part that makes it bite.

18
00:01:10,920 --> 00:01:17,200
PR 57242, from jif-oai, cuts the default

19
00:01:17,240 --> 00:01:21,980
thread_unload_delay_secs from 1800 seconds
to 60.

20
00:01:23,280 --> 00:01:28,220
Before, an idle thread with no subscribers
stayed in memory for thirty minutes,

21
00:01:28,780 --> 00:01:33,600
so queueing from another terminal usually
landed on a loaded thread and looked like

22
00:01:33,660 --> 00:01:34,120
it worked.

23
00:01:35,420 --> 00:01:38,860
Now an idle thread can be unloaded after
one minute.

24
00:01:39,860 --> 00:01:44,500
The release notes just say reduce the
default thread unload delay to one minute.

25
00:01:45,600 --> 00:01:49,840
The reading that the server now reclaims
resources aggressively and the caller

26
00:01:49,900 --> 00:01:54,640
decides whether to wake the thread comes
from a third party write up by DataAgent,

27
00:01:55,100 --> 00:01:57,300
so treat that part as their
interpretation.

28
00:01:58,210 --> 00:01:59,210
Let me make that concrete.

29
00:01:59,790 --> 00:02:04,130
Say a cron job fires every fifteen minutes
and queues a message saying run the

30
00:02:04,190 --> 00:02:04,510
checks.

31
00:02:05,030 --> 00:02:08,070
The thread went idle a few minutes ago, so
it's already unloaded.

32
00:02:08,930 --> 00:02:12,730
Codex queue exits with success, because
the message was accepted.

33
00:02:13,130 --> 00:02:14,510
But nothing is executing.

34
00:02:15,130 --> 00:02:19,310
In the issue, the reporter's launcher also
skipped adding new reminders while the

35
00:02:19,370 --> 00:02:24,210
previous one was still pending, so the
delays stretched to hours with every exit

36
00:02:24,270 --> 00:02:25,050
code green.

37
00:02:25,830 --> 00:02:29,150
Success from queue means accepted, not
running.

38
00:02:29,650 --> 00:02:31,630
That's the operational trap with the new
default.

39
00:02:32,633 --> 00:02:39,313
So CI runners, git hooks, cron, a second
terminal pane, anything that pushes

40
00:02:39,393 --> 00:02:43,553
work into a thread nobody is watching, is
exposed after you upgrade.

41
00:02:44,413 --> 00:02:47,173
It's silent, which is the worst kind of
change.

42
00:02:47,755 --> 00:02:48,395
Now the fix.

43
00:02:48,955 --> 00:02:50,995
Add the resume flag to codex queue.

44
00:02:51,575 --> 00:02:54,015
After queueing, Codex checks the thread
status.

45
00:02:54,475 --> 00:02:58,475
If the thread is loaded and active, it
leaves it alone, and the queued message gets

46
00:02:58,535 --> 00:02:59,375
picked up naturally.

47
00:02:59,995 --> 00:03:05,735
If the thread reports notLoaded, it calls
thread/resume, which wakes it and

48
00:03:05,775 --> 00:03:07,195
dispatches the queued submission.

49
00:03:07,795 --> 00:03:12,875
A command looks like this: codex queue,
thread, your session name or UUID,

50
00:03:13,415 --> 00:03:18,015
message, run the test suite and fix lint
failures, then the resume flag.

51
00:03:18,713 --> 00:03:22,293
The thread argument takes a UUID or an
exact session name.

52
00:03:22,993 --> 00:03:26,653
Per the write up's reading of the source,
names only match active sessions,

53
00:03:27,133 --> 00:03:30,593
and a miss gives you No active session
found matching your name.

54
00:03:31,313 --> 00:03:33,613
So name your long running sessions on
purpose.

55
00:03:34,473 --> 00:03:37,633
For a remote server, add the remote flag
with your endpoint,

56
00:03:38,053 --> 00:03:42,613
then thread nightly migration, message
continue with the next batch,

57
00:03:43,013 --> 00:03:43,473
and resume.

58
00:03:44,313 --> 00:03:50,753
And if you'd rather have the old lifetime,
put thread_unload_delay_secs equals

59
00:03:50,813 --> 00:03:52,733
1800 in your config dot toml.

60
00:03:53,333 --> 00:03:55,033
Setting it to zero unloads immediately.

61
00:03:55,897 --> 00:03:56,517
Caveat one.

62
00:03:56,957 --> 00:03:58,717
Queueing and resuming are decoupled.

63
00:03:59,237 --> 00:04:02,797
If the message is queued but the resume
fails, the command does not fail.

64
00:04:03,237 --> 00:04:06,717
It prints Warning, message was queued, but
could not resume thread,

65
00:04:06,957 --> 00:04:09,777
to stderr, and the message stays
persisted.

66
00:04:10,317 --> 00:04:12,437
That's reasonable, because your message
isn't lost.

67
00:04:12,857 --> 00:04:16,577
But in a script, an exit code of zero
doesn't prove the wake up worked.

68
00:04:17,056 --> 00:04:19,457
Capture stderr and alert on that warning.

69
00:04:20,100 --> 00:04:23,800
Caveat two, from PR 57273.

70
00:04:24,540 --> 00:04:29,320
Codex queue now rejects options it can't
honor instead of ignoring them.

71
00:04:30,340 --> 00:04:35,780
A model flag, or a config override for
model, is rejected, because queued messages

72
00:04:35,900 --> 00:04:37,620
run on the thread's existing model.

73
00:04:38,620 --> 00:04:40,100
Image attachments are rejected.

74
00:04:40,800 --> 00:04:44,880
A prompt passed as a positional argument
without the message flag is rejected.

75
00:04:45,760 --> 00:04:48,700
The cd flag combined with remote is
rejected.

76
00:04:49,480 --> 00:04:54,120
And the no daemon flag without remote is
rejected, because queue needs a running

77
00:04:54,260 --> 00:04:55,120
shared app server.

78
00:04:55,860 --> 00:04:57,200
Also, queue appends.

79
00:04:57,540 --> 00:04:59,400
It does not interrupt an active turn.

80
00:05:00,120 --> 00:05:05,420
One thing nobody has documented: when,
during a long turn, a queued message actually

81
00:05:05,440 --> 00:05:05,920
gets read.

82
00:05:06,460 --> 00:05:09,960
The release notes don't say, and the write
up flags it as worth testing.

83
00:05:10,440 --> 00:05:13,380
Try a harmless task before you wire it
into automation.

84
00:05:13,783 --> 00:05:16,743
A few smaller things in 0.166.0.

85
00:05:17,403 --> 00:05:22,203
Safety blocks in the TUI for biosecurity
and cybersecurity policies now explain

86
00:05:22,243 --> 00:05:26,883
themselves and offer safer rewrites, which
fork from the turn before the block with

87
00:05:26,903 --> 00:05:27,743
your draft intact.

88
00:05:28,503 --> 00:05:32,083
The npm wrapper now hands off to the
native binary with execve,

89
00:05:32,903 --> 00:05:37,083
so there's one less Node process in the
chain and signals behave more directly.

90
00:05:37,903 --> 00:05:42,403
Markdown renders consistently in async
questions, answers, and transcript replies.

91
00:05:43,143 --> 00:05:48,023
And codex doctor with the network only
flag checks config, proxy environment,

92
00:05:48,563 --> 00:05:53,483
HTTP reachability and the WebSocket
handshake, skipping the database and MCP scans.

93
00:05:54,040 --> 00:05:57,440
Action item for today: grep your scripts
for codex queue.

94
00:05:58,060 --> 00:06:02,440
Every call that targets a thread nobody is
watching either gets the resume flag,

95
00:06:02,900 --> 00:06:05,800
or you raise thread_unload_delay_secs.

96
00:06:06,280 --> 00:06:07,720
Then watch stderr for that warning.