Alpha Compaction Bug Wipes Long-Running Context

Ethan Park

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.

Maya

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?

Ethan Park

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%!

Maya

Ten percent? That's barely even getting started.

Ethan Park

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.

Maya

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?

Ethan Park

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.

Maya

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?

Ethan Park

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.

Maya

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.

Ethan Park

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.

Maya

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?

Ethan Park

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.

Maya

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?

Ethan Park

Oh, the, uh, the webview crash loop? Yes. It's a complete mess.

Maya

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.

Ethan Park

Wait, why three seconds? Is there a hard-coded retry loop in the extension host?

Maya

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.

Ethan Park

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.

Maya

Wait, is this the config leak in $CODEX_HOME/agents/?

Ethan Park

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.

Maya

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?

Ethan Park

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.

Maya

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.

Ethan Park

Right, the dangerous command protection. They specifically targeted a broader array of forced rm CLI variations, right?

Maya

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.

Ethan Park

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.

Maya

Definitely. Alright, I think that's our cue. Talk to you next time, Ethan.

Ethan Park

Yep, see ya.