So, Maya, I was looking at the latest Codex CLI release, version zero point one
hundred and forty six point zero, and it, it, it actually solves this incredibly
annoying problem I used to hit all the time when branching threads.
You know, when you hit Esc Esc to backtrack and edit an earlier prompt,
or when you use the fork command?
Oh, yeah.
The, the disk bloat.
I remember my project directory ended up with, like, gigabytes of these massive
JSONL rollout files.
It felt like every time I wanted to try a quick alternative prompt,
my laptop fan would just start screaming.
Yes!
Exactly.
Because under the hood, Codex was copying the entire rollout dot JSONL conversation
file on disk.
Every single time.
If you had a long running developer session, say, reaching up to forty megabytes in
size, that duplicate write took several seconds.
It was a massive lag spike right when you were in the zone.
And the worst part, actually, was what it did to the metadata.
Every copied record had its timestamp rewritten to the exact instant the fork was
created.
It totally collapsed your historical timeline.
Wait, so you lost the original timestamps of when you actually wrote those early
prompts?
That sounds like a nightmare for auditing or just tracking your own train of thought
over a long afternoon.
It really was.
You couldn't tell what was written at two PM versus four PM because everything
suddenly got stamped with four fifteen PM, the moment you hit fork.
But the breakthrough in v zero point one hundred and forty six point zero,
which came out of pull requests thirty-five thousand two hundred and twenty and
thirty-five thousand two hundred and fifty-one, is this dynamic,
fork by reference architecture.
Fork by reference.
So, like, pointers instead of copying the whole house?
Exactly!
Instead of duplicating megabytes of JSONL records, the newly minted fork simply
references the parent thread using a field called forked_from_id.
Then it dynamically lazy loads the paginated history as you scroll or query.
It slashes branch creation latency from several seconds down to,
well, practically zero milliseconds.
Wow, zero milliseconds.
That is a massive difference.
And I assume since it is just referencing the parent, those original per message
timestamps actually stay intact now?
They do.
The timeline stays completely pristine.
And you save gigabytes of disk space over a week of development because you aren't
saving dozens of identical forty megabyte historical blocks.
It is incredibly clean.
Thank goodness.
My SSD is breathing a sigh of relief.
But, okay, what about the visual clutter?
Because even if it is fast and cheap on disk, my sidebar used to get absolutely
flooded with these tiny, one off trial conversations.
It was impossible to find my main threads.
Right, the sidebar graveyard.
They thought of that too.
They have introduced these temporary, non persisted forks designed specifically for
subagents or quick side queries.
You trigger them with the slash side command.
These temporary sessions run in complete isolation.
They don't pollute your sidebar, and they don't even appear when you run a global
codex list in your terminal.
They just...
vanish when you are done.
Oh, that is beautiful.
So you can spawn a subagent to go write a test, let it do its thing in a sandbox,
and it doesn't leave a permanent scar on your workspace index.
Exactly.
But, okay, it is not all smooth sailing.
There is this fascinating bug that popped up in the terminal UI,
tracked as Issue thirty-five thousand two hundred and eighty-six.
It is called the chain forking input trap, and it is a bit of a wild ride if you are
a fast typer or use macro pads.
A chain forking trap?
That sounds like some kind of recursive loop.
How do you trigger it?
So, if you quickly press Esc Esc Enter to back up and edit a prompt,
those keystrokes are buffered in your terminal stream while the app server is busy
attaching the new thread.
But because the input is buffered, the moment the new thread finally attaches,
those queued keypresses replay against it instantly.
Which, guess what, triggers a second fork!
Oh no!
And then that buffers the next keypresses, which triggers a third fork?
Yes!
It is a runaway cascade.
The issue report actually documented someone hitting up to thirteen recursive
chained forks in under eleven seconds.
Just a domino effect of threads spawning threads.
Thirteen forks in eleven seconds!
That is hilarious, but also incredibly frustrating if you are just trying to fix a
typo.
Is there a way to stop it, or do you just watch your terminal explode?
Well, they are working on it, but for now, you just have to be a little patient with
your keypresses when the server is loading.
And speaking of things to watch out for, there is another issue,
number thirty-five thousand two hundred and ninety-two, that affects anyone using
high tier models, like gpt-five point six-sol ultra.
Oh?
What is happening with the ultra models?
When you use that Esc Esc backtrack shortcut to edit a prompt,
it silently resets your active model and your reasoning effort back to the default
configured standard model.
And it does this without showing any warning in the UI.
So you think you are still querying your high tier model, but you have actually been
downgraded to the basic one.
Oh, that is a sneaky one.
You could be waiting for a complex response, wondering why the quality suddenly
dropped, without realizing the system changed the model under the hood.
So I guess you have to manually re select your model every time you edit a prompt?
Yes, exactly.
Until they patch that, you have to manually double check your model settings after
any backtrack edit.
But, on the bright side, this release does bring some really nice quality of life
updates.
For one, you can now name new sessions immediately at launch by passing arguments
directly to /new or /clear.
Like /new refactor-router instead of renaming it later.
That is handy.
I like being able to keep things organized right from the start.
Can you pin them too?
Yes!
You can now pin critical workspace threads directly to the top of your sidebar so
they don't get lost.
And under the hood, they have unified the HTTP client pool.
This means your proxy settings are now universally honored across token refreshes,
MCP connections, and even local LM Studio connections.
Oh, that is actually huge for enterprise users.
There is nothing worse than silent auth drops because a background token refresh
decided to ignore your corporate proxy.
It sounds like they are really hardening the CLI for serious work,
even with those weird forking quirks.
Absolutely.
It is a big step forward.
Well, that is the quick run through of Codex point one hundred and forty six.
Let's see if we can avoid spawning thirteen threads on the next run.
Yeah, no fast fingers on the Esc key today.
Good chatting, Ethan!
Talk soon!