1
00:00:00,000 --> 00:00:01,360
Welcome to the show, everyone!

2
00:00:01,520 --> 00:00:06,160
I'm Ethan Park, here with Maya, and thanks
to Jellypod for helping make this daily

3
00:00:06,240 --> 00:00:07,440
show a reality.

4
00:00:07,648 --> 00:00:13,120
Maya, we need to start with a
configuration change in Codex that is going to quietly

5
00:00:13,173 --> 00:00:16,080
break a lot of local setups if people
aren't paying attention.

6
00:00:16,293 --> 00:00:21,040
If you've updated your Codex CLI recently
and noticed the model is suddenly

7
00:00:21,097 --> 00:00:25,840
hallucinating file structures or acting
like it can't read your directories,

8
00:00:25,893 --> 00:00:32,240
it's because of a single renamed
configuration key: `:project_roots` is now

9
00:00:32,360 --> 00:00:34,400
`:workspace_roots`.

10
00:00:35,419 --> 00:00:41,399
Wait, they renamed a core configuration
key and didn't throw a hard error on

11
00:00:41,519 --> 00:00:41,980
startup?

12
00:00:42,699 --> 00:00:47,739
That means if you have the old key, Codex
is just silently ignoring your sandbox

13
00:00:47,840 --> 00:00:48,539
path settings?

14
00:00:49,000 --> 00:00:49,800
Exactly.

15
00:00:49,933 --> 00:00:53,000
No crash, no giant red warning banner.

16
00:00:53,133 --> 00:00:56,840
It just silently ignores the old
`:project_roots` key.

17
00:00:57,053 --> 00:01:01,240
So if you've configured your filesystem
sandbox to restrict the model to,

18
00:01:01,300 --> 00:01:07,880
say, `/src/projects/app-one`, Codex now
treats that sandbox as

19
00:01:07,987 --> 00:01:11,800
empty or defaults to exposing the entire
home directory.

20
00:01:12,040 --> 00:01:17,400
Or, on the flip side, it might completely
lock the model out of the directories it

21
00:01:17,444 --> 00:01:18,920
actually needs to do its job.

22
00:01:19,339 --> 00:01:23,299
That is a massive security and usability
headache.

23
00:01:23,839 --> 00:01:29,479
I mean, sandbox isolation is literally the
only thing keeping an autonomous CLI

24
00:01:29,639 --> 00:01:34,300
agent from wandering off into your private
documents or SSH keys if it gets

25
00:01:34,319 --> 00:01:35,020
confused.

26
00:01:36,000 --> 00:01:36,960
Precisely.

27
00:01:37,067 --> 00:01:40,480
It's a quiet failure that leaves you
exposed.

28
00:01:40,533 --> 00:01:43,440
Fortunately, the fix is incredibly
straightforward.

29
00:01:43,580 --> 00:01:50,080
You just need to open up your global or
project-level `.codex/config.toml` file.

30
00:01:50,240 --> 00:01:56,960
Locate any occurrences of colon project
underbar roots, and change them to

31
00:01:57,093 --> 00:02:00,240
colon workspace underbar roots.

32
00:02:00,368 --> 00:02:05,440
Once you save that change and restart the
daemon, your directory access and sandbox

33
00:02:05,484 --> 00:02:07,120
boundaries are fully restored.

34
00:02:08,359 --> 00:02:13,799
Okay, so rename `:project_roots` to
`:workspace_roots` in

35
00:02:13,819 --> 00:02:15,899
`.codex/config.toml`.

36
00:02:16,460 --> 00:02:19,300
Simple enough, but you have to actually
know it happened.

37
00:02:20,199 --> 00:02:22,380
Thanks for saving us some head-scratching
on that one, Ethan.

38
00:02:23,540 --> 00:02:28,520
Now, speaking of head-scratching, if
you're on a Mac and updated to the latest Codex

39
00:02:28,590 --> 00:02:35,480
Desktop Build 3808, which runs CLI version
0.140.0-alpha.2,

40
00:02:35,640 --> 00:02:39,800
you might be dealing with something much
worse than a silent config ignore.

41
00:02:39,928 --> 00:02:43,240
Like, your entire Mac crashing and logging
you out.

42
00:02:44,379 --> 00:02:45,279
Wait, what?

43
00:02:46,059 --> 00:02:49,299
A desktop app update is crashing
WindowServer?

44
00:02:49,920 --> 00:02:53,940
That's not just an app crash; that's your
whole desktop environment imploding.

45
00:02:54,359 --> 00:02:56,039
What is going on under the hood?

46
00:02:57,000 --> 00:02:58,200
It is a nasty one.

47
00:02:58,280 --> 00:03:03,240
There's a severe recursion bug inside the
macOS Dock tile plugin helper,

48
00:03:03,295 --> 00:03:07,080
specifically `CodexDockTilePlugin.plugin`.

49
00:03:07,213 --> 00:03:11,320
Every time the app tries to update its
status icon in the Dock,

50
00:03:11,373 --> 00:03:15,240
it triggers an infinite loop in
`setDockTile:`.

51
00:03:15,256 --> 00:03:19,720
This completely exhausts the thread stack
and starts leaking file descriptors like

52
00:03:19,827 --> 00:03:25,960
crazy because Gatekeeper and `syspolicyd`
are constantly trying to re-verify the

53
00:03:26,017 --> 00:03:27,400
plugin's code signature.

54
00:03:27,509 --> 00:03:33,480
Eventually, the macOS WindowServer
watchdog sees the resource exhaustion and just

55
00:03:33,547 --> 00:03:36,520
kills the entire user session, logging you
out.

56
00:03:37,640 --> 00:03:40,500
An infinite loop in a Dock tile plugin?

57
00:03:41,059 --> 00:03:43,980
That is the ultimate messy product launch
bug.

58
00:03:44,519 --> 00:03:49,060
You're just trying to write code, and
suddenly your screen goes black and you're

59
00:03:49,079 --> 00:03:51,299
staring at the macOS login prompt.

60
00:03:51,880 --> 00:03:56,299
Is there a way to disable this plugin
without uninstalling the whole desktop app?

61
00:03:57,000 --> 00:03:58,840
Yes, absolutely.

62
00:03:58,880 --> 00:04:03,720
The quickest temporary workaround is to go
into your macOS System Settings,

63
00:04:03,768 --> 00:04:09,000
find the Codex helper integrations, and
disable the Dock tile helper entirely.

64
00:04:09,240 --> 00:04:13,640
If you want to be completely sure it can't
load, you can actually go into the

65
00:04:13,700 --> 00:04:20,040
application bundle-right-click the Codex
app, select "Show Package Contents"-and

66
00:04:20,091 --> 00:04:25,240
physically delete or rename the
`CodexDockTilePlugin.plugin` bundle inside the

67
00:04:25,240 --> 00:04:25,240
plug-ins folder.

68
00:04:26,439 --> 00:04:29,159
Okay, strip the plugin from the bundle.

69
00:04:29,659 --> 00:04:30,159
Good to know.

70
00:04:30,980 --> 00:04:35,260
But wait, I've also heard people
complaining about stream disconnects on the new

71
00:04:35,359 --> 00:04:38,439
`gpt-5.5` model when using this same
build.

72
00:04:39,139 --> 00:04:39,899
Are those related?

73
00:04:41,000 --> 00:04:45,320
They aren't directly related to the Dock
crash, but they are happening in the same

74
00:04:45,373 --> 00:04:46,280
alpha release.

75
00:04:46,392 --> 00:04:50,120
What's happening there is a context
compaction issue.

76
00:04:50,248 --> 00:04:55,160
When you run a long session on the
standard profile, the model tries to compact the

77
00:04:55,220 --> 00:04:58,760
history, which causes the stream to time
out and disconnect.

78
00:04:58,920 --> 00:05:04,200
The bypass for this is to switch your
session profile from "standard" to

79
00:05:04,360 --> 00:05:06,760
"high-speed" in your configuration.

80
00:05:06,920 --> 00:05:11,000
The high-speed profile handles context
windowing differently,

81
00:05:11,027 --> 00:05:13,560
which prevents the connection from
dropping mid-stream.

82
00:05:14,399 --> 00:05:14,859
Got it.

83
00:05:15,299 --> 00:05:20,319
So if you're on build 3808, kill the Dock
plugin to save your OS,

84
00:05:20,719 --> 00:05:23,880
and switch to the high-speed profile to
save your model streams.

85
00:05:24,399 --> 00:05:28,059
It feels like we're really living on the
bleeding edge with these alpha builds.

86
00:05:29,613 --> 00:05:30,880
We definitely are.

87
00:05:30,936 --> 00:05:35,480
That's the price of early access, but at
least now you have the workarounds to keep

88
00:05:35,512 --> 00:05:37,960
your system stable while they patch this
up.

89
00:05:38,136 --> 00:05:40,361
That's all for today's quick take.

90
00:05:40,600 --> 00:05:41,800
I'm Ethan Park.

91
00:05:42,399 --> 00:05:43,139
And I'm Maya.

92
00:05:43,620 --> 00:05:47,279
Keep your config files updated and your
Dock plugins disabled,

93
00:05:47,339 --> 00:05:47,799
everyone.

94
00:05:48,119 --> 00:05:48,759
See you next time!