1
00:00:00,360 --> 00:00:01,040
Morning, everyone.

2
00:00:01,820 --> 00:00:05,500
Thanks to Jellypod for helping make this
daily show a reality.

3
00:00:06,420 --> 00:00:12,440
Today we're staying on one topic: what
happens to your turn when context compaction

4
00:00:12,540 --> 00:00:14,740
goes wrong in the Codex app server.

5
00:00:15,620 --> 00:00:19,260
Two reports from the last week point at
the same corner of the system,

6
00:00:19,800 --> 00:00:21,120
and one of them has a fix.

7
00:00:22,022 --> 00:00:22,942
Start with the fixed one.

8
00:00:23,262 --> 00:00:30,242
It's issue 54897, reproduced on the
0.164.0 alpha 3

9
00:00:30,522 --> 00:00:35,462
macOS arm64 binary against a loopback
Responses backend.

10
00:00:36,002 --> 00:00:40,442
The symptom is a turn that stays
inProgress with error null,

11
00:00:40,882 --> 00:00:41,282
forever.

12
00:00:41,802 --> 00:00:45,042
The reporter waited 30 seconds and saw no
terminal event.

13
00:00:45,838 --> 00:00:46,878
The mechanism is small.

14
00:00:47,498 --> 00:00:49,638
Codex can compact context in the
background.

15
00:00:50,338 --> 00:00:54,138
There's a function called take_ready that
polls a one shot channel for the

16
00:00:54,158 --> 00:00:54,898
background result.

17
00:00:55,538 --> 00:00:59,418
It called try_recv and then dot ok with a
question mark.

18
00:01:00,118 --> 00:01:03,718
If the channel was Closed, meaning the
background task had already failed,

19
00:01:04,218 --> 00:01:07,178
it returned early without clearing the
stored receiver.

20
00:01:07,818 --> 00:01:12,298
Later, when foreground compaction needed
to wait, it polled that already completed

21
00:01:12,338 --> 00:01:15,298
receiver and panicked with "called after
complete."

22
00:01:16,007 --> 00:01:18,787
And the process doesn't die, which is the
nasty part.

23
00:01:19,207 --> 00:01:21,567
The panic kills the task, not the server.

24
00:01:22,007 --> 00:01:24,627
So your client sees a turn that never
finishes.

25
00:01:25,127 --> 00:01:30,127
The reporter also found that sending
another turn/start returned the same turn ID

26
00:01:30,487 --> 00:01:32,207
without making a model request.

27
00:01:32,607 --> 00:01:34,007
So retrying doesn't help.

28
00:01:34,725 --> 00:01:38,545
The reproduction is worth knowing because
it tells you when you'd hit this.

29
00:01:39,325 --> 00:01:45,465
Async compaction enabled, context window
set to 100,000, auto compaction limit at

30
00:01:45,705 --> 00:01:46,265
90,000.

31
00:01:47,045 --> 00:01:53,045
A response reports 70,000 tokens, which
crosses the default 65 percent threshold and

32
00:01:53,165 --> 00:01:54,445
starts background compaction.

33
00:01:55,105 --> 00:01:58,685
Then that background stream closes before
response.completed.

34
00:01:59,465 --> 00:02:05,225
The reporter says it also reproduces with
an HTTP 400 or with missing compaction

35
00:02:05,285 --> 00:02:05,605
output.

36
00:02:06,465 --> 00:02:11,285
Next, a response reports 91,000 tokens,
foreground compaction is required,

37
00:02:11,585 --> 00:02:12,585
and the panic fires.

38
00:02:13,265 --> 00:02:16,705
Those counts are synthetic, but the app
server code was unmodified.

39
00:02:17,392 --> 00:02:18,672
The recovery is concrete.

40
00:02:19,172 --> 00:02:23,032
Call turn/interrupt on the stuck turn,
then start a new turn,

41
00:02:23,392 --> 00:02:24,332
and the thread works again.

42
00:02:24,852 --> 00:02:26,572
Other threads were unaffected the whole
time.

43
00:02:27,272 --> 00:02:31,392
The issue closed on October 20, and the
reporter wrote that it was fixed by pull

44
00:02:31,432 --> 00:02:33,412
request 55581.

45
00:02:34,052 --> 00:02:38,172
The source I have doesn't say which
release carries it, so check your version rather

46
00:02:38,192 --> 00:02:38,712
than assuming.

47
00:02:39,292 --> 00:02:45,872
The stable npm tag was still 0.163.0 at
last look, with 0.164.0

48
00:02:45,952 --> 00:02:48,292
alphas shipping nearly every few hours.

49
00:02:48,903 --> 00:02:55,323
Now the open one, issue 54822, and this
one matters if you build on

50
00:02:55,383 --> 00:02:57,143
thread/queue/add.

51
00:02:57,883 --> 00:03:02,803
The reporter shows that an input accepted
by that call can vanish from both the

52
00:03:02,883 --> 00:03:07,463
queue and persisted history when pre turn
compaction is interrupted.

53
00:03:08,263 --> 00:03:15,123
They tested 0.163.0 and 0.164.0 alpha 3,
and saw the

54
00:03:15,183 --> 00:03:17,623
same on 0.162.1.

55
00:03:18,430 --> 00:03:20,290
Walk through the sequence, because it's
precise.

56
00:03:20,850 --> 00:03:24,850
Seed message goes in through
thread/queue/add and completes.

57
00:03:25,450 --> 00:03:29,110
A second message is queued with a unique
clientUserMessageId.

58
00:03:29,710 --> 00:03:34,410
The client waits for an item/started event
of type contextCompaction,

59
00:03:34,910 --> 00:03:37,810
then calls turn/interrupt on that turn.

60
00:03:38,590 --> 00:03:42,810
After the turn completes as interrupted,
and even after restarting the app server,

61
00:03:43,210 --> 00:03:44,470
the follow up is gone.

62
00:03:44,970 --> 00:03:48,650
The queue holds zero entries, there are
zero matching user messages,

63
00:03:49,030 --> 00:03:52,470
and the raw rollout doesn't contain the
client ID or the text.

64
00:03:52,810 --> 00:03:54,130
The seed message survives.

65
00:03:54,798 --> 00:03:57,818
Two caveats from the report itself, and
they matter.

66
00:03:58,538 --> 00:04:04,138
First, the reporter forced the boundary by
setting model_auto_compact_token_limit to

67
00:04:04,378 --> 00:04:10,898
1 and project_doc_max_bytes to 0, so this
doesn't establish how often it happens at

68
00:04:10,938 --> 00:04:11,798
default settings.

69
00:04:12,638 --> 00:04:17,118
Second, it ran on Windows through a
Responses compatible gateway,

70
00:04:17,678 --> 00:04:22,778
not direct OpenAI authentication, and the
reporter says a direct run hasn't been

71
00:04:22,818 --> 00:04:23,038
done.

72
00:04:23,818 --> 00:04:27,838
They also say the exact Rust cancellation
path isn't instrumented,

73
00:04:28,298 --> 00:04:30,058
so no root cause is proven.

74
00:04:30,770 --> 00:04:32,030
So what do you do today?

75
00:04:32,790 --> 00:04:34,970
This part is my interpretation, not from
the issue.

76
00:04:35,510 --> 00:04:39,150
If your integration interrupts during a
contextCompaction item,

77
00:04:39,630 --> 00:04:42,170
don't assume an accepted queue add is
durable.

78
00:04:42,770 --> 00:04:47,930
Before resubmitting, page through
thread/turns/list and look for your

79
00:04:47,990 --> 00:04:49,430
clientUserMessageId.

80
00:04:50,110 --> 00:04:54,370
The issue's expected behavior says
recovery shouldn't force a client to blindly

81
00:04:54,430 --> 00:04:58,630
resend work that may have executed, so
checking first is the cautious path.

82
00:04:59,338 --> 00:05:05,978
One more detail: a related fix, 53932,
preserves history when compaction

83
00:05:06,138 --> 00:05:06,518
fails.

84
00:05:07,198 --> 00:05:10,838
The alpha tested already included it and
still lost the input.

85
00:05:11,438 --> 00:05:14,618
So that fix protects the history, but not
this window.

86
00:05:15,432 --> 00:05:16,512
A few smaller items.

87
00:05:17,032 --> 00:05:20,292
First, if /voice in the CLI disconnects
almost immediately,

88
00:05:20,852 --> 00:05:24,472
issue 55531 has a detailed write up on
macOS.

89
00:05:25,072 --> 00:05:30,452
The CLI shows "voice audio session stopped
unexpectedly" or transport_closed.

90
00:05:30,952 --> 00:05:34,552
The reporter captured the underlying error
on the WebRTC data channel,

91
00:05:35,112 --> 00:05:37,832
usage_check_failed, which the native
helper ignores.

92
00:05:38,412 --> 00:05:45,352
It reproduced across 0.162.1, 0.163.0 and
0.164.0 alpha

93
00:05:45,792 --> 00:05:45,812
6.

94
00:05:46,445 --> 00:05:48,765
And be careful with what it proves.

95
00:05:49,665 --> 00:05:54,545
The reporter's strongest guess is a
service side usage or entitlement check,

96
00:05:55,285 --> 00:05:59,225
but they say the internal reason and
affected scope are unknown.

97
00:06:00,325 --> 00:06:03,125
Ordinary usage showed as allowed in the
same account.

98
00:06:04,045 --> 00:06:08,005
Text mode keeps working, and it's the only
fallback found so far.

99
00:06:08,985 --> 00:06:13,725
Downgrading, TCP only and IPv4 only didn't
help.

100
00:06:14,593 --> 00:06:16,293
Second, the standalone installers.

101
00:06:16,753 --> 00:06:23,713
Per the 0.163.0 package readme, they
download from releases.openai.com by default

102
00:06:24,113 --> 00:06:28,253
and fall back to GitHub Releases if
metadata or an asset download fails.

103
00:06:28,873 --> 00:06:30,513
To force GitHub, set

104
00:06:30,713 --> 00:06:37,533
CODEX_INSTALLER_USE_RELEASES_OPENAI_COM to
false.

105
00:06:38,133 --> 00:06:39,853
Zero and no are also accepted.

106
00:06:40,453 --> 00:06:43,233
On Mac or Linux, put it in front of the
shell in the curl pipe.

107
00:06:43,773 --> 00:06:46,713
On Windows, set it in PowerShell before
running the install script.

108
00:06:47,333 --> 00:06:50,233
That's useful if your network allows one
host and not the other.

109
00:06:50,962 --> 00:06:53,762
Third, a date to check against your
configs.

110
00:06:54,542 --> 00:06:59,842
The changelog says GPT 5.5 retired from
Codex on October 14,

111
00:07:00,262 --> 00:07:03,842
at noon Pacific, for users signed in with
ChatGPT.

112
00:07:04,902 --> 00:07:08,442
API key sessions and the OpenAI API aren't
affected.

113
00:07:09,422 --> 00:07:15,322
The suggested replacement is GPT 6.1 Sol,
when available to your plan and client.

114
00:07:16,182 --> 00:07:21,042
So search workspace defaults, managed
configurations, custom agents,

115
00:07:21,542 --> 00:07:25,702
scheduled tasks and scripts for any
leftover 5.5 selection.

116
00:07:26,412 --> 00:07:27,112
That's the roundup.

117
00:07:27,552 --> 00:07:32,672
Interrupt a stuck turn before you retry
it, and verify queued input before you

118
00:07:32,712 --> 00:07:33,292
resend it.