A 13-Day Code Review Exposed the Lie at the Heart of OpenClaw's Session System

The bug was laughably simple. OpenClaw's session tools accept a sessionKey parameter. AI agents — the LLMs orchestrating conversations — naturally pass sessionKey: "current" when they want to check the status of whatever session they're currently in. It's the most obvious alias imaginable. “What session am I in?”

OpenClaw's session system didn't recognize it. The word “current” was treated as a literal session key — as if you had a session literally named “current” — and when no such session existed, the system threw an error. Every agent that asked the most basic possible question about its own state got an exception.

The fix is conceptually trivial: normalize “current” to the requester's own session ID before doing the lookup. BryanTegomoh opened a PR on March 9 with exactly that fix, scoped to the session_status tool.

Then the review started.

What the Review Actually Revealed

Here's what I find interesting about this PR. It's not the bug. It's not the fix. It's the fact that a reviewer named obviyus looked at a perfectly functional two-line patch and said: “No. This is too narrow.”

That reviewer was right. The session_status tool wasn't the only one that needed to understand “current.” So did sessions_history and sessions_send. If BryanTegomoh had fixed only session_status, the same bug would have surfaced in two other tools the moment an agent tried to use them.

The 13-day review forced the fix into the shared resolution layer: resolveSessionReference and resolveInternalSessionKey. It also required registering “current” as a canonical key in looksLikeSessionKey to prevent the classifier from routing it to a literal name-based lookup.

That's good engineering. That's a review process that works. But let me ask the uncomfortable question: why did OpenClaw's session resolution layer not handle “current” from the start? This isn't an obscure edge case. It's the single most common session query an AI agent would make. The system was designed for agents and didn't anticipate that agents would ask about their own session.

The Performance Fixes That Shipped Alongside

While BryanTegomoh's session fix went through its 13-day review, vincentkoc was working on the other end of the session lifecycle: what happens when a session starts.

Put these three PRs together and you get a complete picture of OpenClaw's session problem on March 22. Sessions didn't know what “current” meant. Sessions loaded 169 MB before they could process a reply. Sessions rebuilt the model catalog from scratch every time an agent spoke. The session system was technically functional and practically hostile to anyone trying to use it.

The 13-Day Question

I want to end on the review process, because it's the part of this story that cuts both ways.

On one hand: a 13-day review for a session alias fix is thorough. The reviewer caught a design flaw. The author iterated. The final code is architecturally sound. 24 tests pass. This is how open source is supposed to work.

On the other hand: for 13 days, every agent on the platform that tried to check its own session status got an error. The bug was known. The fix was in review. The users were waiting.

There's a tension in open-source development between “get it right” and “get it shipped.” The best projects find a middle path: merge the narrow fix immediately to stop the bleeding, then open a follow-up for the architectural cleanup. OpenClaw chose thoroughness over speed. That's a defensible choice. But it means their users absorbed two weeks of errors so the codebase could be clean.

“The best review processes are fast and thorough. The worst are slow and superficial. OpenClaw's was slow and thorough. That's the second-best outcome, and it's not clear anyone noticed the cost.”

The session system knows what “current” means now. The cold start loads 1.9 MB instead of 169 MB. The model catalog caches between turns. These are real improvements, earned through real review. I just wish they'd shipped thirteen days sooner.