Codex Config Rename and Mac Crash Workarounds

Ethan Park

Welcome to the show, everyone! I'm Ethan Park, here with Maya, and thanks to Jellypod for helping make this daily show a reality. Maya, we need to start with a configuration change in Codex that is going to quietly break a lot of local setups if people aren't paying attention. If you've updated your Codex CLI recently and noticed the model is suddenly hallucinating file structures or acting like it can't read your directories, it's because of a single renamed configuration key: `:project_roots` is now `:workspace_roots`.

Maya

Wait, [questioning tone] they renamed a core configuration key and didn't throw a hard error on startup? That means if you have the old key, Codex is just silently ignoring your sandbox path settings?

Ethan Park

Exactly. No crash, no giant red warning banner. It just silently ignores the old `:project_roots` key. So if you've configured your filesystem sandbox to restrict the model to, say, `/src/projects/app-one`, Codex now treats that sandbox as empty or defaults to exposing the entire home directory. Or, on the flip side, it might completely lock the model out of the directories it actually needs to do its job.

Maya

That is a massive security and usability headache. [skeptical] I mean, sandbox isolation is literally the only thing keeping an autonomous CLI agent from wandering off into your private documents or SSH keys if it gets confused.

Ethan Park

Precisely. It's a quiet failure that leaves you exposed. Fortunately, the fix is incredibly straightforward. You just need to open up your global or project-level `.codex/config.toml` file. Locate any occurrences of colon project underbar roots, and change them to colon workspace underbar roots. Once you save that change and restart the daemon, your directory access and sandbox boundaries are fully restored.

Maya

Okay, so rename `:project_roots` to `:workspace_roots` in `.codex/config.toml`. Simple enough, but you have to actually know it happened. [chuckles] Thanks for saving us some head-scratching on that one, Ethan.

Ethan Park

[sighs] Now, speaking of head-scratching, if you're on a Mac and updated to the latest Codex Desktop Build 3808, which runs CLI version 0.140.0-alpha.2, you might be dealing with something much worse than a silent config ignore. Like, your entire Mac crashing and logging you out.

Maya

Wait, what? [gasps] A desktop app update is crashing WindowServer? That's not just an app crash; that's your whole desktop environment imploding. What is going on under the hood?

Ethan Park

It is a nasty one. There's a severe recursion bug inside the macOS Dock tile plugin helper, specifically `CodexDockTilePlugin.plugin`. Every time the app tries to update its status icon in the Dock, it triggers an infinite loop in `setDockTile:`. This completely exhausts the thread stack and starts leaking file descriptors like crazy because Gatekeeper and `syspolicyd` are constantly trying to re-verify the plugin's code signature. Eventually, the macOS WindowServer watchdog sees the resource exhaustion and just kills the entire user session, logging you out.

Maya

An infinite loop in a Dock tile plugin? [scoffs] That is the ultimate messy product launch bug. You're just trying to write code, and suddenly your screen goes black and you're staring at the macOS login prompt. Is there a way to disable this plugin without uninstalling the whole desktop app?

Ethan Park

Yes, absolutely. The quickest temporary workaround is to go into your macOS System Settings, find the Codex helper integrations, and disable the Dock tile helper entirely. If you want to be completely sure it can't load, you can actually go into the application bundle—right-click the Codex app, select "Show Package Contents"—and physically delete or rename the `CodexDockTilePlugin.plugin` bundle inside the plug-ins folder.

Maya

[thoughtfully] Okay, strip the plugin from the bundle. Good to know. But wait, I've also heard people complaining about stream disconnects on the new `gpt-5.5` model when using this same build. Are those related?

Ethan Park

They aren't directly related to the Dock crash, but they are happening in the same alpha release. What's happening there is a context compaction issue. When you run a long session on the standard profile, the model tries to compact the history, which causes the stream to time out and disconnect. The bypass for this is to switch your session profile from "standard" to "high-speed" in your configuration. The high-speed profile handles context windowing differently, which prevents the connection from dropping mid-stream.

Maya

Got it. So if you're on build 3808, kill the Dock plugin to save your OS, and switch to the high-speed profile to save your model streams. It feels like we're really living on the bleeding edge with these alpha builds.

Ethan Park

[chuckles] We definitely are. That's the price of early access, but at least now you have the workarounds to keep your system stable while they patch this up. That's all for today's quick take. I'm Ethan Park.

Maya

And I'm Maya. Keep your config files updated and your Dock plugins disabled, everyone. See you next time!