You know, thanks to Jellypod for helping us bring this show out daily,
but...
okay, if you have ever run a multi day agentic refactoring session in Codex,
you know the absolute horror of the sidebar.
It just turns into this endless, linear, scrolling avalanche.
And then, er, you try to open a transcript with like a hundred plus turns,
and your whole TUI just freezes solid while it tries to render giant logs.
Oh, I, I have been there!
It is, uh, complete terminal paralysis.
You sit there watching your screen freeze while it loads every single line of text
from three days ago.
Exactly.
But in Codex zero point one four seven point zero, they finally addressed this head
on.
Maya, what did they actually change in the sidebar state?
Right, so pull requests thirty five seven two two, thirty six zero zero seven,
and thirty six three eight zero bring in proper persistent thread sections.
So instead of just sorting strictly by recency or having a flat pinned list,
you can actually organize conversations into persistent, manually ordered sections
right inside your sidebar.
Wait, manually ordered sections?
So I can, like, build a dedicated section for my database migration agent,
and another one for API refactoring, and they just stay where I put them?
Yes!
Exactly that.
They don't jump around every time an automated background run pings a session.
You drag or assign them into custom groups, and those groups persist across
restarts.
It stops the sidebar chaos completely.
Man, that is huge for long running projects.
But what about that TUI freeze when you actually click into one of those huge
threads?
How did they fix the rendering lag?
So that was pull requests thirty six nine four eight, thirty six nine five zero,
and thirty six nine eight three.
Basically, they ripped out the old behavior where the entire transcript was shoved
into memory all at once.
Now, you can browse long transcripts incrementally.
Wait, browse long transcripts incrementally?
How does that work under the hood with the SQLite database?
They implemented paginated queries using includeTurns against the local SQLite state
database.
So when you open a session with a hundred or two hundred turns,
it only fetches and renders the slice of history you are actively viewing.
As you scroll up or down, it pulls the next chunk incrementally.
Zero terminal redraw lag.
Wow, that is...
that is night and day compared to forcing the terminal buffer to parse three
megabytes of raw json text instantly.
But, uh, speaking of that SQLite database, aren't there a few caveats with how state
locks work now?
Oh, absolutely.
That is pull request thirty six three eight nine.
The local state DB now strictly enforces single writer thread history constraints.
So if you have multiple agent subprocesses trying to write back to the exact same
thread state simultaneously, you will hit lock exceptions unless they queue up
properly.
Right, single writer locks.
And what happens when someone upgrades to zero point one four seven point zero and
opens a legacy session file from an older version?
They thought of that too.
Pull request thirty seven one seven five adds an automatic legacy rollout migration.
The first time you launch zero point one four seven point zero,
it detects your older pre upgrade session files and migrates their schema into the
new persistent section format in the background.
It is pretty seamless, but if you have custom scripts mutating the raw DB,
you need to be aware of that schema shift.
Now, beyond the thread history stuff, there is a massive security update in zero
point one four seven point zero that I think every developer needs to know about.
Especially if you share terminal recordings or replay conversation logs publicly.
Ah, you mean the secret filtering changes?
Yes!
Pull requests thirty six eight nine three and thirty six nine zero eight introduce
automatic redaction across the board.
The engine will now redact secrets and complete bearer tokens from displayed
commands and replayed conversation history.
Wait, complete bearer tokens?
So if an agent executes a curl command with a authorization header containing a raw
OAuth token or an API key, it gets scrubbed automatically?
Scrubbed completely before it ever hits your stdout rendering or your persistent
replay logs.
In earlier versions, if an agent echoed a command, that full bearer token was saved
verbatim in the TUI replay buffer.
If you replayed that session on a stream or attached it to a bug report,
boom, your secret was leaked.
Now, it detects those patterns and masks them fully.
That is going to save so many people from accidentally revoking their API keys on
live streams!
That is a massive safety net.
It really is.
And on top of security, they also squashed some extremely annoying TUI input bugs
that were driving people crazy.
Oh, like the dreaded terminal freeze when switching windows?
Exactly!
Pull requests thirty five six four nine, thirty five nine five seven,
and thirty six eight three four.
If you were using Ghostty or certain multiplexers, clicking away from the terminal
and coming back would often cause lost keypresses, or stick the TUI input in a
frozen state where it ignored keyboard focus completely.
That, plus background MCP server startup hangs, are all resolved now.
That Ghostty shortcut handling bug was brutal.
Glad that is fixed.
Now, what about opening unfamiliar projects?
I saw something about directory trust?
Right, pull requests thirty six nine six zero and thirty seven one three two.
Codex now enforces an explicit directory trust guard when you open or target an
unfamiliar repository.
Before it reads workspace configuration or executes any local tools,
it prompts you to confirm that you trust the repository root.
So an agent cannot just silently execute malicious workspace settings embedded in an
untrusted repo you just cloned?
Precisely.
It halts execution until you explicitly grant trust for that folder path.
So if we sum this up for someone updating their environment today...
set up your persistent thread sections in the sidebar to clean up your workspace,
rest easy knowing long transcripts browse incrementally without crashing your TUI,
and make sure your team verifies their SQLite state locks if they run parallel agent
orchestrations.
Spot on.
That is zero point one four seven point zero in a nutshell.
Good stuff as always, Maya.
Definitely.
Talk to you tomorrow, Ethan!