Hey everyone, welcome to the show!
I'm Ethan Park, here with Maya, and a quick shoutout before we dive in: thanks to
Jellypod for helping make this daily show a reality.
Today we are looking at the Codex CLI 0.139.0 release, and they've
introduced a feature that solves a massive headache for me.
Code mode can now call a standalone web search directly, even from deep inside
nested JavaScript tool calls.
Wait, nested JavaScript tool calls?
So, if you're running a script inside the CLI and it hits a wall with an external
API, the script itself can trigger a search query?
Exactly.
Think about when you're writing a script to automate an integration,
and suddenly you get a 404 because the API endpoint changed yesterday.
Instead of the LLM throwing its hands up or forcing you to drop out of your tool
chain, Codex can issue a direct web search to grab the latest docs,
pull the correct schema, and keep executing.
Okay, that's incredibly useful for things like undocumented npm updates.
But how is it handling the data payload?
Web pages are notoriously noisy.
If it's sucking down raw HTML or even heavy markdown, you're going to blow through
your token context window in seconds.
They actually thought of that.
The engine bypasses heavy markdown parsing entirely.
It streamlines the query and returns flat, clean plaintext.
No massive HTML tables, no complex nested lists -- just the text.
But the flip side is you have to write incredibly precise queries.
If you search for something generic like "react error," you'll just get a wall of
unhelpful text.
Right, because you don't have visual cues or layout structure to help filter the
signal from the noise.
It makes you realize how much we rely on formatting.
So, if I'm feeding this stack traces, I need to make sure the CLI query targeting is
super specific -- like targeting the exact error code and package version.
Precisely.
You want to pass things like the exact npm package version and the specific method
name.
If you do that, the plaintext return is incredibly efficient.
It's basically a surgical strike for documentation.
That efficiency focus seems to carry over to how they're handling schemas in this
release too.
I saw they did some serious hardening on the Model Context Protocol,
or MCP, schemas.
Apparently, large tool and connector schemas now preserve `oneOf` and `allOf`
structures during compaction.
Oh, thank goodness.
Previously, when Codex tried to compact those massive JSON schemas to save tokens,
it would occasionally flatten or strip out `oneOf` and `allOf` blocks.
And if you're relying on strict custom validation for complex API payloads,
losing those logical operators completely breaks your runtime validation.
It's the worst.
You end up with a compacted schema that says any input is fine,
and then your backend crashes because a required mutually exclusive field was
missing.
Preserving those structures means we keep custom MCP validation fully intact,
even after compaction.
And speaking of things breaking under the hood, they also cleaned up some CLI
argument parsing bugs.
If you ran `codex resume --last` or `codex fork --last` with a
trailing string, the parser used to get confused.
It would try to interpret that trailing string as a session ID instead of the new
prompt you wanted to run.
Ah, the classic CLI ambiguity.
So if you typed `codex resume --last "refactor the auth route"`,
it would look for a session called "refactor the auth route" and error out.
Exactly.
It was a frustrating papercut.
In 0.139.0, that's fixed.
It correctly identifies the trailing string as your new input prompt for the resumed
session.
They also updated `codex doctor` -- it now prints out your local editor and pager
details, but they've safely redacted sensitive raw values in the JSON outputs so you
don't accidentally leak API keys when sharing debug logs.
That's a smart touch.
It's those little developer-experience guardrails that make a tool feel mature.
It shows they're thinking about the real-world environments where these tools
actually run.
Absolutely.
It makes you wonder how long before we see these clean plaintext search patterns
become the default for all developer-facing LLM integrations.
That's all for today's quick take.
I'm Ethan Park.
And I'm Maya.
We'll see you in the next one.