1
00:00:00,180 --> 00:00:07,070
So I- I- I was looking at the pull
requests for the new Codex CLI 0.143.0

2
00:00:07,140 --> 00:00:11,760
alpha this morning, and thanks to Jellypod
to help make this daily show a reality,

3
00:00:12,280 --> 00:00:16,560
we have a concrete fix for that nasty
plugin block we ran into last week.

4
00:00:17,220 --> 00:00:22,620
It turns out, if you tried to run /import
on any of your old Claude Code

5
00:00:22,700 --> 00:00:27,400
configurations, the whole thing would
just, like, fall over with a massive

6
00:00:27,600 --> 00:00:28,599
validation error.

7
00:00:29,140 --> 00:00:32,229
And it all came down to a single JSON
schema failure.

8
00:00:32,905 --> 00:00:35,154
Wait, a schema failure?

9
00:00:35,174 --> 00:00:39,494
Was it actually rejecting valid Claude
Code plugins just because of the metadata?

10
00:00:41,170 --> 00:00:41,710
Exactly.

11
00:00:42,330 --> 00:00:47,290
Specifically, in the hooks/hooks.json file
inside the plugin package.

12
00:00:47,850 --> 00:00:51,150
Claude Code allows a top-level description
field in there to,

13
00:00:51,570 --> 00:00:53,250
you know, explain what the hooks are
doing.

14
00:00:53,870 --> 00:01:00,230
But the Codex parser in 0.142.x had this
incredibly strict JSON

15
00:01:00,350 --> 00:01:03,850
schema that didn't recognize description
at that level.

16
00:01:03,860 --> 00:01:08,870
So, instead of ignoring it, the CLI just
threw a validation exception and aborted

17
00:01:08,880 --> 00:01:10,710
the entire import process.

18
00:01:13,302 --> 00:01:13,303
That's wild.

19
00:01:13,392 --> 00:01:19,792
So a harmless piece of documentation in
the JSON literally bricked the migration?

20
00:01:19,832 --> 00:01:23,232
I- I mean, that's classic strict
validation hurting usability.

21
00:01:24,043 --> 00:01:27,923
Yeah, it- it's the classic "fail shut"
approach when you really want to fail open.

22
00:01:28,603 --> 00:01:35,323
But PR 30229, which just landed in the
0.143.0-alpha,

23
00:01:35,363 --> 00:01:36,493
relaxes that parser.

24
00:01:37,203 --> 00:01:41,583
It basically tells the schema validator to
ignore extra metadata fields like

25
00:01:41,603 --> 00:01:44,323
description, so the hooks can actually
load.

26
00:01:44,923 --> 00:01:50,363
But, Maya, if you're stuck on the stable
0.142 branch right now and can't jump to

27
00:01:50,403 --> 00:01:52,303
the alpha, you don't have to wait.

28
00:01:52,903 --> 00:01:54,663
There's a quick local workaround.

29
00:01:55,182 --> 00:01:56,670
Oh, nice!

30
00:01:56,831 --> 00:01:59,531
Let me guess, we can just manually edit
the cache?

31
00:02:00,051 --> 00:02:02,971
Where is Codex actually storing these
downloaded plugins?

32
00:02:03,665 --> 00:02:04,285
Precisely.

33
00:02:04,765 --> 00:02:07,645
You want to head into your home directory,
and look for

34
00:02:07,664 --> 00:02:12,685
~/.codex/plugins/cache/.

35
00:02:14,085 --> 00:02:17,405
In there, you'll find the directories for
each imported plugin.

36
00:02:18,045 --> 00:02:24,205
If you open up the offending plugin's
directory, find that hooks/hooks.json file,

37
00:02:24,825 --> 00:02:27,885
and literally just delete the line with
the "description" key,

38
00:02:28,455 --> 00:02:32,825
the 0.142 engine will load it up perfectly
on the next run.

39
00:02:33,465 --> 00:02:34,925
No more validation crashes.

40
00:02:35,688 --> 00:02:38,778
Okay, that's super easy to hot-patch.

41
00:02:38,898 --> 00:02:45,818
Just ~/.codex/plugins/cache/, find the
hook JSON, and strip the

42
00:02:45,858 --> 00:02:46,378
description.

43
00:02:47,098 --> 00:02:50,118
Good to know we have an escape hatch while
the alpha stabilizes.

44
00:02:51,214 --> 00:02:57,823
Speaking of stable releases, 0.142.2
quietly dropped some really big

45
00:02:57,863 --> 00:03:02,263
quality-of-life updates for the Model
Context Protocol, or MCP.

46
00:03:02,303 --> 00:03:05,793
They've actually enabled MCP tool search
by default now.

47
00:03:06,363 --> 00:03:12,543
But the thing I'm most relieved about is
the new respect_system_proxy config flag.

48
00:03:12,563 --> 00:03:15,983
If you've ever tried to run Codex behind a
corporate firewall on macOS,

49
00:03:16,503 --> 00:03:20,383
you know it's a nightmare with PAC or WPAD
configurations.

50
00:03:21,487 --> 00:03:22,537
Oh, tell me about it.

51
00:03:23,187 --> 00:03:28,757
System proxies on macOS are notoriously
tricky for CLI tools because they don't

52
00:03:28,847 --> 00:03:35,607
always respect the standard HTTP_PROXY
environment variables if the network

53
00:03:35,627 --> 00:03:37,987
uses an automatic proxy discovery script.

54
00:03:39,476 --> 00:03:39,477
Yes!

55
00:03:39,546 --> 00:03:42,936
That's exactly why they added
respect_system_proxy.

56
00:03:43,546 --> 00:03:48,326
When you toggle that on in your Codex
config, the Go runtime under the hood actually

57
00:03:48,406 --> 00:03:53,506
queries the macOS System Configuration
framework directly, so it can resolve those

58
00:03:53,646 --> 00:03:58,106
enterprise PAC files and route your MCP
tool search requests properly.

59
00:03:58,646 --> 00:04:01,686
No more silent timeouts when you're on the
office VPN.

60
00:04:02,548 --> 00:04:04,428
That is huge for enterprise users.

61
00:04:04,968 --> 00:04:08,788
But, uh, speaking of silent failures and
weird resource usage...

62
00:04:09,488 --> 00:04:12,588
we have to talk about issue 29755.

63
00:04:13,268 --> 00:04:18,488
This is an active bug in the Amazon
Bedrock provider, and it's a bit of a disaster

64
00:04:18,548 --> 00:04:21,368
if you monitor your log sizes or token
usage.

65
00:04:22,982 --> 00:04:22,983
Oh?

66
00:04:22,983 --> 00:04:24,132
What's going on with Bedrock?

67
00:04:24,552 --> 00:04:26,012
Is it a rate-limiting thing?

68
00:04:27,338 --> 00:04:27,718
Worse.

69
00:04:28,178 --> 00:04:30,738
It's a streaming chunk accumulation bug.

70
00:04:31,318 --> 00:04:35,478
So, normally, when you stream a response
from Bedrock, the provider is supposed to

71
00:04:35,538 --> 00:04:39,458
send back deltas-you know, just the new
tokens as they arrive.

72
00:04:39,998 --> 00:04:45,298
But right now, the Bedrock wrapper is
logging these as cumulative snapshots in the

73
00:04:45,358 --> 00:04:49,578
local rollout .jsonl session files.

74
00:04:49,658 --> 00:04:55,918
Meaning, chunk one is "Hello", chunk two
is "Hello world", chunk three is "Hello

75
00:04:55,978 --> 00:04:57,598
world from", and so on.

76
00:04:58,721 --> 00:04:58,981
Wait.

77
00:04:59,041 --> 00:05:03,941
So it's writing the entire accumulated
history of the response to the log file with

78
00:05:04,121 --> 00:05:05,821
every single new token?

79
00:05:06,461 --> 00:05:09,841
That must make those .jsonl files grow
exponentially!

80
00:05:10,617 --> 00:05:11,257
Exactly!

81
00:05:11,677 --> 00:05:13,257
It- it scales quadratically.

82
00:05:13,897 --> 00:05:18,317
If you have a long response, your session
log file can balloon to megabytes for a

83
00:05:18,417 --> 00:05:19,057
single prompt.

84
00:05:19,617 --> 00:05:22,717
And the real kicker is how it handles
token tracking.

85
00:05:23,377 --> 00:05:28,347
Because it's parsing these cumulative
snapshots, the token counting logic is getting

86
00:05:28,397 --> 00:05:34,257
tripped up, especially if you're
outputting multi-byte characters like CJK-Chinese,

87
00:05:34,577 --> 00:05:39,657
Japanese, or Korean-where character
boundaries get split across chunk boundaries.

88
00:05:40,257 --> 00:05:45,237
It starts miscalculating your actual
usage, which can throw off your local token

89
00:05:45,317 --> 00:05:45,937
budget limits.

90
00:05:46,643 --> 00:05:48,733
That is a massive trap.

91
00:05:49,213 --> 00:05:54,113
Especially if you're relying on those
local session logs for debugging or auditing.

92
00:05:54,833 --> 00:05:59,053
Is there a fix in the works, or do we have
to manually manage these logs?

93
00:05:59,847 --> 00:06:04,087
There's an active fix being tested in the
main branch right now that properly

94
00:06:04,187 --> 00:06:09,387
flushes only the deltas to the .jsonl
rollouts, but until that's promoted out of

95
00:06:09,467 --> 00:06:14,867
alpha, the best mitigation is to regularly
prune your local session history or

96
00:06:14,927 --> 00:06:19,327
temporarily switch your provider backend
if you are running massive generation

97
00:06:19,367 --> 00:06:19,767
tasks.

98
00:06:20,547 --> 00:06:23,427
Keep an eye on those file sizes in your
workspace directory.

99
00:06:24,049 --> 00:06:24,758
Definitely.

100
00:06:25,198 --> 00:06:29,558
Well, that's a solid heads-up for anyone
running heavy Bedrock workflows today.

101
00:06:30,138 --> 00:06:31,658
Alright, good chatting, talk soon!

102
00:06:32,611 --> 00:06:33,711
Yep, catch you next time.