1
00:00:00,091 --> 00:00:03,520
So, I was in Warp yesterday, typing out a
quick system prompt,

2
00:00:04,020 --> 00:00:07,210
and the moment I hit the @ key to pull up
a file reference,

3
00:00:07,760 --> 00:00:10,340
my entire terminal process just...

4
00:00:10,450 --> 00:00:10,800
hung.

5
00:00:11,490 --> 00:00:13,050
Totally unresponsive.

6
00:00:13,720 --> 00:00:19,660
It turns out the new unified mentions
menu, the mentions_v2 system that's supposed

7
00:00:19,700 --> 00:00:25,640
to merge files, plugins, and skills into
one dropdown, has been absolutely wrecking

8
00:00:25,660 --> 00:00:29,420
terminal user interface keyboard
navigation for a lot of devs.

9
00:00:30,758 --> 00:00:33,207
Wait, the whole terminal hung?

10
00:00:33,947 --> 00:00:35,747
Just from typing an @ symbol?

11
00:00:37,327 --> 00:00:37,787
That's...

12
00:00:38,667 --> 00:00:40,667
that is a massive headache for a workflow.

13
00:00:41,627 --> 00:00:45,387
I'm guessing it's some kind of rendering
loop conflict with the TUI?

14
00:00:46,168 --> 00:00:46,828
Exactly.

15
00:00:47,248 --> 00:00:52,428
It's a terminal emulator conflict,
specifically with how the rich rendering in

16
00:00:52,488 --> 00:00:56,288
mentions_v2 handles keyboard focus.

17
00:00:56,308 --> 00:01:00,428
But look, if you're hitting this right now
and just need your terminal back,

18
00:01:00,468 --> 00:01:02,548
there's an immediate, persistent fix.

19
00:01:03,088 --> 00:01:08,958
You just run codex features disable
mentions_v2 directly in your shell.

20
00:01:09,448 --> 00:01:14,508
That drops you right back to the classic,
file-only mention UI and instantly

21
00:01:14,528 --> 00:01:16,008
restores keyboard stability.

22
00:01:16,726 --> 00:01:21,086
Okay, codex features disable mentions_v2.

23
00:01:21,166 --> 00:01:22,646
That's good to know.

24
00:01:22,706 --> 00:01:26,896
Thanks to Jellypod to help make this daily
show a reality, because tracking down

25
00:01:26,926 --> 00:01:31,146
these breaking terminal bugs is basically
a full-time job.

26
00:01:31,166 --> 00:01:35,326
But what's actually happening under the
hood to cause that lockup?

27
00:01:35,386 --> 00:01:37,166
Is it just a bad keybind map?

28
00:01:37,913 --> 00:01:38,783
It's a bit of both.

29
00:01:39,333 --> 00:01:43,313
The root issue was how they were rendering
the active selection in the terminal

30
00:01:43,353 --> 00:01:43,633
loop.

31
00:01:44,233 --> 00:01:49,153
They were using a heavy reverse-video
styling to highlight the selected item in the

32
00:01:49,193 --> 00:01:49,513
menu.

33
00:01:50,193 --> 00:01:54,113
In terminal emulators, especially
hardware-accelerated ones like Warp,

34
00:01:54,623 --> 00:01:57,873
that repaint cycle was fighting with the
input focus loop.

35
00:01:58,573 --> 00:02:04,353
If you look at pull request #28959, which
just hit the alpha channel in version

36
00:02:04,593 --> 00:02:11,082
0.143.0-alpha.36, they completely

37
00:02:11,193 --> 00:02:12,093
re-engineered this.

38
00:02:13,396 --> 00:02:16,695
Wait, they got rid of the reverse-video
styling entirely?

39
00:02:17,225 --> 00:02:19,125
How do you even see what you're selecting
then?

40
00:02:19,850 --> 00:02:24,020
They replaced it with a dedicated
two-character gutter on the left side of the menu.

41
00:02:24,780 --> 00:02:30,150
Inside that gutter, they draw a simple >
active pointer, combined with some subtle,

42
00:02:30,620 --> 00:02:34,720
theme-adaptive row accents that don't
trigger the heavy repaint.

43
00:02:35,520 --> 00:02:42,480
Along with that, PR #28959 explicitly maps
Ctrl-P, Ctrl-N,

44
00:02:43,080 --> 00:02:48,780
Tab, and Enter directly in the TUI input
loop, so the terminal doesn't intercept

45
00:02:48,820 --> 00:02:51,339
those keys while the mention menu is
active.

46
00:02:52,659 --> 00:02:53,289
Ah, got it.

47
00:02:53,849 --> 00:02:58,839
So instead of forcing the terminal to
redraw the entire background block of the

48
00:02:58,909 --> 00:03:03,429
selected text, it's just moving a tiny
two-character pointer in the gutter.

49
00:03:04,009 --> 00:03:05,478
That makes so much more sense.

50
00:03:05,829 --> 00:03:08,119
It's way lighter on the terminal's
rendering engine.

51
00:03:09,048 --> 00:03:10,128
Exactly.

52
00:03:10,268 --> 00:03:14,368
Much cleaner, and it stops the input loop
from freezing up when you're trying to

53
00:03:14,488 --> 00:03:15,448
arrow through your files.

54
00:03:16,712 --> 00:03:22,492
Well, speaking of things breaking, if
you're on Windows or using the Plus API,

55
00:03:22,512 --> 00:03:25,972
there are two pretty nasty regressions
that cropped up this week.

56
00:03:26,612 --> 00:03:29,872
The first is a straight-up crash in the
Windows desktop app,

57
00:03:30,412 --> 00:03:35,072
and the second is a silent quota drain
that's costing people money while they're

58
00:03:35,172 --> 00:03:36,432
literally asleep.

59
00:03:37,262 --> 00:03:38,851
Wait, a silent quota drain?

60
00:03:39,642 --> 00:03:44,782
Like, your ChatGPT Plus rate limit is
ticking down even when you aren't sending

61
00:03:44,802 --> 00:03:45,282
requests?

62
00:03:46,062 --> 00:03:47,322
Yes, exactly.

63
00:03:47,882 --> 00:03:52,122
But let's look at the Windows app first
because that one is very loud.

64
00:03:52,762 --> 00:03:59,742
If you updated to version 26.623.101652,
which rolled out on

65
00:03:59,762 --> 00:04:03,102
July 3, you've probably noticed the client
just...

66
00:04:03,762 --> 00:04:04,382
vanishes.

67
00:04:05,062 --> 00:04:09,762
There's an unhandled exception in the
wrapper that force-closes the entire desktop

68
00:04:09,842 --> 00:04:14,842
window almost exactly five minutes after
you launch it, regardless of whether you're

69
00:04:14,922 --> 00:04:17,602
actively typing or if it's just sitting in
the background.

70
00:04:19,136 --> 00:04:19,816
Five minutes?

71
00:04:20,336 --> 00:04:22,816
That's an incredibly specific window.

72
00:04:22,896 --> 00:04:26,756
Is it a memory leak in the Electron
wrapper, or something with the session

73
00:04:26,836 --> 00:04:27,336
heartbeat?

74
00:04:27,979 --> 00:04:33,309
It seems to be a heartbeat timeout check
that fails silently and triggers a hard

75
00:04:33,469 --> 00:04:34,999
exit instead of a reconnect.

76
00:04:35,539 --> 00:04:39,719
They're working on a hotfix, but for now,
you're better off rolling back or using

77
00:04:39,729 --> 00:04:40,509
the web interface.

78
00:04:41,309 --> 00:04:43,689
Now, the quota issue is weirder.

79
00:04:44,199 --> 00:04:49,729
People are checking their usage and
finding their 5-hour ChatGPT Plus backend API

80
00:04:49,769 --> 00:04:55,379
quota is reporting one hundred percent
usage, even after long idle periods where

81
00:04:55,409 --> 00:04:58,009
they haven't run a single session.

82
00:04:58,041 --> 00:05:02,441
That's incredibly frustrating, especially
if you're trying to get work done and you

83
00:05:02,501 --> 00:05:03,681
hit an artificial ceiling.

84
00:05:04,441 --> 00:05:09,041
Is there a client-side workaround, or is
this entirely a backend accounting bug?

85
00:05:09,733 --> 00:05:13,513
It's mostly a backend reporting issue, but
if you're on macOS,

86
00:05:13,733 --> 00:05:17,933
there's actually a really clever
workaround using the third-party **CodexBar**

87
00:05:17,953 --> 00:05:18,983
utility.

88
00:05:18,984 --> 00:05:22,403
They just pushed an update with a built-in
idle-climb detector.

89
00:05:23,073 --> 00:05:26,723
What it does is it actively polls the
local file modification times,

90
00:05:26,933 --> 00:05:32,173
the mtimes, of your session cache and
compares them against your OAuth token status.

91
00:05:32,253 --> 00:05:36,502
If it detects the backend is reporting a
usage drift while those local mtimes are

92
00:05:36,513 --> 00:05:41,233
completely static, it flags the drift and
can actually force-refresh your session

93
00:05:41,273 --> 00:05:43,353
token to halt the silent accounting drain.

94
00:05:44,026 --> 00:05:44,156
Huh.

95
00:05:44,886 --> 00:05:48,856
That's a remarkably clean way to handle a
backend bug from the client side.

96
00:05:49,526 --> 00:05:54,526
Polling the local mtimes to prove you're
idle, and then cycling the OAuth token to

97
00:05:54,606 --> 00:05:56,866
force the backend to reset its session
state.

98
00:05:57,546 --> 00:06:00,206
I might have to pull down that CodexBar
update tonight.

99
00:06:00,868 --> 00:06:04,888
Yeah, it's a lifesaver if you're
constantly hitting those weird,

100
00:06:04,928 --> 00:06:06,508
phantom rate limits.

101
00:06:06,528 --> 00:06:11,348
Definitely worth installing until the
official API endpoint gets sorted out.

102
00:06:11,379 --> 00:06:11,919
For sure.

103
00:06:12,479 --> 00:06:15,599
Alright, I'm going to go apply that
terminal fix to my config.

104
00:06:16,139 --> 00:06:17,539
Good chatting, talk soon.

105
00:06:19,285 --> 00:06:19,715
Sounds good, catch you later.