Welcome to the show everybody!
I'm Ethan Park, here with Maya, and first off, a huge shoutout to Jellypod for
supporting the show.
Maya, let's jump straight into the command line because Codex CLI just dropped
version 0.137.0, and they've also kicked off the 0.138.0
alpha stream.
If you are managing developer environments at scale, this one is a massive shift in
how we handle configuration.
Right because up until now configuring codecs across a massive engineering org was
let's face it a bit of a nightmare You were basically pushing static files around
But 0 137 0 introduces these cloud managed config bundles and full support for
EDU workspaces This means admins can finally distribute global policies directly
from the cloud settings portal Exactly.
No more writing custom script packages just to update a timeout setting or change a
default model across five hundred developer laptops.
You set it in the cloud portal, and the local CLI pulls down those global policies.
And they added a neat little quality-of-life feature to the local CLI status bar too
-- it now displays monthly enterprise credit limits directly to the developer in
real-time.
Oh I love that It's like a utility bill meter right there in your terminal There is
nothing worse than running a massive batch processing script only to realize halfway
through that you've hit your enterprise cap and everything is erroring out It's
direct feedback where the developer actually looks It is super practical.
But, because this is a point-one-three-seven release, we have to talk about where
the paint is still a little wet.
There are some really fascinating deserialization gaps in this centralized model
that you will run into immediately if you try to roll this out today.
Specifically, if you try to set the `model` or the new
`model_reasoning_effort`
parameter inside those global cloud policies, the local CLI completely ignores them.
Wait interrupts why would it just ignore them If the admin sets a global policy in
the cloud saying everyone uses Cloud 3 5 Sonnet how does the CLI just skip that It
comes down to a classic mismatch in the serialization code.
Under the hood, the Codex CLI is built in Rust, and there is a specific struct
called `ConfigRequirementsToml` that handles parsing these incoming settings.
When they updated the cloud schema to support pushing down model names and reasoning
efforts, they simply forgot to update that Rust struct to deserialize those specific
keys.
So the JSON payload comes down from the cloud, the Rust parser looks at it,
doesn't see those fields in the struct definition, and just silently discards them.
Wow So the data is literally flying over the wire hitting the machine and then just
evaporating because the parser doesn't have a slot to put it in That is a classic
early version slip But wait even if they fix that deserialization bug in the 0 138 0
alpha isn't there another issue with how local state interacts with these global
policies Yes!
This is the local state override problem.
Codex uses a local SQLite database on the developer's machine to persist thread
state -- things like your chat history, active sessions, and local context.
Right now, when you resume a session, that persisted SQLite thread state
automatically overrides whatever global model definitions are coming down from the
cloud.
Ahh so even if the Cloud Config could tell the CLI to use a specific model the
second a developer resumes an existing thread from their local SQLiteDB the database
says nope we were using this other model 5 minutes ago so we're switching back to
that Local state wins Exactly.
SQLite trumps cloud config.
So if you're an admin trying to force a transition to a cheaper or more secure
model, your users are still going to be running on their old local defaults whenever
they resume a thread.
The only real workaround right now is to have developers manually clear their local
thread database or specify the model flag explicitly in their local commands,
which completely defeats the purpose of centralized control.
It's a messy middle ground And speaking of centralized control what about deep
infrastructure settings Like if I want to route all my developer telemetry through a
corporate open telemetry collector can I do that through this new cloud portal
Unfortunately, no.
Not yet.
Centralized telemetry settings, like your OpenTelemetry endpoints and headers,
still lack any kind of UI coverage in the cloud settings portal.
If you want to manage those, you are back to the old-school method: you have to
physically place a `managed_config.toml` file onto the developer's filesystem using
an MDM tool like Jamf or Intune.
So we're in this hybrid state We have this beautiful vision of a single cloud
dashboard in 0 137 0 But in practice engineers are still going to be balancing cloud
policies local SQLite overrides and MDM pushed TOML files just to keep their
developer fleets in sync It's a step forward but you definitely need to keep your
automation scripts handy Definitely.
It feels like the foundation is solid, but we'll be watching the 0.138.0 alpha
stream very closely to see how quickly they patch these structural gaps.
That's our take on Codex CLI 0.137.0.
Thanks for listening, and we'll catch you in the next one.
See ya