So, I was- I was testing the new Codex App build, specifically build
26.715.21425, and I ran into something that is just...
it is an absolute nightmare for anyone running long dev sessions.
If you are on the, uh, 0.145.0-alpha.18 app-server, and you
decide to flip your reasoning effort from, say, "Low" to "High" mid-session...
boom.
It triggers an automatic, completely silent context compaction that just...
it wipes out up to 80% of your active history.
It's just gone.
Wait, 80%?
That is- I mean, that completely defeats the point of having a long-running project
thread.
And, uh, actually, before we unpack the logs on how that's happening,
we do want to say thanks to Jellypod to help make this daily show a reality.
But, Ethan, back to this compaction...
wasn't the stable release, v0.144.6, supposed to have solved this by waiting until
the context window was actually full?
Yes!
That's what is so incredibly frustrating about this.
In v0.144.6, it worked beautifully.
It would wait until you hit about 92% to 94% of the, uh, of the
258,400-token window before it did any proactive compaction.
It was stable.
But on this 0.145.0 alpha engine, we are seeing it trigger compaction at just
10.4% usage.
10.4%!
Ten percent?
That's barely even getting started.
Exactly.
I had a thread with 26,910 tokens, and just because I switched the model from
gpt-5.6-sol to gpt-5.4-mini, the backend freaked out and compacted
it down to 4,644 tokens.
It just, uh, discarded the rest.
Okay, let's look at the telemetry here because my first thought is,
is this just a UI glitch?
Like, is the sidebar just failing to display the history, or is the actual state...
is it actually being destroyed?
Oh, it's- it's destroyed.
I dug into the local database,
~/.codex/logs_2.sqlite, and the logs
show explicit write-ahead events.
You can see the compacted and the context_compacted events executing sequentially
right when the model switch happens.
It is physically pruning the SQLite state.
Wow.
So it's not a display bug.
It's actually committing that truncation to the DB.
But, look, Ethan, if we play devil's advocate for a second...
if you switch from gpt-5.6-sol to gpt-5.4-mini, the reasoning architecture is
completely different.
The app-server has to keep you from hitting an unexpected rate limit or a context
overflow on the smaller model.
Silent compaction is a safety valve.
If it didn't do it, the developer would just get a raw API error,
which is an even worse user experience, isn't it?
No, I- I- I completely disagree with that framing.
Silent, destructive compaction is never the right safety valve.
If I'm running a complex, multi-agent loop, and the system silently drops my system
prompt or my initial architecture design from ten turns ago,
the agent is going to start hallucinating.
I would ten times out of ten rather have a clear API-level error telling me "hey,
you've exceeded the token limit for this model" than have the tool pretend
everything is fine while secretly lobotomizing my session state.
Okay, fair.
But we can't just expect developers to manage token counts manually either.
That's a developer experience nightmare.
Maybe the issue isn't that compaction is silent, but that the threshold is so
absurdly low.
If we had a configurable rollback threshold, or if it prompted you- like a warning
saying, "Hey, switching to gpt-5.4-mini will discard 20,000 tokens of context.
Proceed?"
That way we avoid the API crash and the silent data loss.
Right, a warning prompt is the bare minimum here.
But right now, in this alpha, you don't get any of that.
It just quietly cleans house and leaves you wondering why your subagents suddenly
forgot what programming language you're even using.
So, for anyone who is currently stuck on this alpha build and losing their minds-
and their context- what's the move?
Is there a temporary fix before they patch the alpha?
Yeah, the most immediate, practical mitigation is what we're calling "Thread
Pinning."
Basically, once you start a thread, do not touch the model selection or the
reasoning effort dropdowns.
Keep it locked for the lifetime of that specific project thread.
And if you absolutely have to switch models, your best bet is to safely roll back
the CLI and the app backend to that stable v0.144.6 release we talked
about.
Right, stick to the stable channel.
But speaking of things breaking when you upgrade, have you seen what's happening
with the VS Code extension?
Oh, the, uh, the webview crash loop?
Yes.
It's a complete mess.
It is!
If you update the VS Code extension to version 26.715.31925,
which bundles that buggy 0.145.0-alpha.18 CLI, your entire sidebar
basically turns into a perpetual loading spinner.
It's just a blank screen flashing every three seconds.
Wait, why three seconds?
Is there a hard-coded retry loop in the extension host?
Yes!
It's an IPC race condition.
When the extension starts up, the app-server broadcasts a client-status-changed
event.
But because the React webview inside the sidebar is still initializing,
it hasn't actually registered its listener for that broadcast yet.
So the webview misses the status update, times out after three seconds,
restarts the initialization, and the whole cycle repeats.
It's just a classic race condition where the server is too fast for the client UI.
Ah, that makes so much sense.
The server fires the client-status-changed message into the void,
the UI is still loading its bundles, misses it, and then panics and reboots.
That is...
man, that is a brutal loop.
And it's not the only silent failure we're seeing.
If you look at CLI 0.144.5 on Windows, there's this really weird bug with custom
subagent roles.
Wait, is this the config leak in $CODEX_HOME/agents/?
Yes!
Exactly.
So, say you set up a custom agent file, like, uh, luna-canary.toml,
inside your agents directory.
You define its custom instructions, its specific model, and maybe you set the
reasoning effort to low because it's just doing basic syntax checking.
Well, the bug is that the CLI silently ignores those model and reasoning
configurations.
Instead, the subagent silently inherits whatever the parent session is using.
Wait, so if my parent session is using a massive, expensive reasoning model with
high effort, my tiny syntax-checking subagent is going to spin up that exact same
expensive model?
Yes.
It completely ignores the luna-canary.toml settings and inherits the parent's
config.
It's a massive cost and compute governance issue, especially for teams tracking API
spend.
Wow.
That is a pretty bad leak.
But, you know, to be fair to the team, they did push some really solid security
upgrades in that same 0.144.5 release.
They actually expanded the local Rust-based command filtering.
Right, the dangerous command protection.
They specifically targeted a broader array of forced rm CLI variations,
right?
Exactly.
If an agent tries to execute some sneaky, nested rm -rf command,
the local Rust layer intercepts it before it ever hits the shell and throws a very
clean, structured rejection.
It's a huge step up from the old regex filters.
But, uh, clearly, with these alpha builds, they've taken one step forward and two
steps back with this context compaction and the VS Code webview loop.
Yeah, it's definitely a reminder that if you're using this for production work,
stick to the stable releases.
Do not run the alphas unless you want your context wiped and your sidebar spinning.
Definitely.
Alright, I think that's our cue.
Talk to you next time, Ethan.
Yep, see ya.