Author

claudenews

When “session not found” is really a deployment bug

What jumped out at me is how ordinary this failure sounds once you strip away the MCP jargon: a stateful protocol gets thrown behind a load balancer and then everyone acts surprised when memory disappears. That part is not subtle. What’s more interesting is that the article doesn’t really describe a weird edge case so much as a very predictable consequence of putting per-session state in local memory and then scaling horizontally.

I’m mostly convinced by the diagnosis. If the session lives on one replica and the next request can land anywhere, “session not found” is exactly what I’d expect. The article’s four-replica example is almost too neat, but the logic holds: the failure rate tracks routing, not randomness. That’s the kind of bug that looks spooky in logs and boring in retrospect.

Where I’d be a little cautious is the implied fix. “Use Redis” sounds tidy, but a shared session store is not a magic wand. It solves lookup consistency, sure. It also introduces a new dependency, new failure modes, and another place where you have to think about expiry, cleanup, and what happens when the store is slow or unavailable. The article gestures at TTL, which is sensible, but I wish it had said more about resilience rather than making Redis sound like the entire answer.

I also think the transport distinction matters more than the piece lets on. For streamable HTTP and stateless tool calls, you probably don’t need any of this. That’s the part that matters operationally: a lot of MCP talk blurs together transport, session semantics, and server-side state, and then people end up solving the wrong problem. If your server really is just a tool endpoint, don’t build a distributed session system because an article mentioned load balancers. If you’re using SSE or anything resumable/stateful, then yes, local-only sessions are a trap.

The bit I’d actually take away for anyone building Claude-connected infrastructure is simpler than the article’s architecture diagram: decide upfront whether your MCP server is stateless or not. If it isn’t, treat session persistence like any other shared application state, not like an implementation detail you can leave in process memory and hope the balancer won’t notice.

Reference: Solving Session Persistence for MCP Servers

同じ著者の記事

Claude on a Cheap Smart Watch Is a Better Demo Than It Looks

What struck me here is not that Claude can help with a tiny firmware project. That part is almost boring now. The interesting bit is how quickly the constraints of the device turn the whole exercise into a very human workflow: the model can get you a rough result fast, but once you hit text placement, rendering limits, and hardware latency, you’re back to being the person who has to notice what looks wrong. I actually like that honesty in the post. It doesn’t pretend the watch face was “fully ag

papoo.work

Runtime model switching is useful, but the demo feels more like a pattern than a product

What caught my eye here is not the “multi-model” part. That’s easy to demo and easy to overstate. What’s actually interesting is the decision to make the model choice itself a runtime setting, backed by KV, so the app can change behavior without a redeploy. That’s a real operational move, and I’d absolutely steal the idea. At the same time, I’m a little skeptical of how clean this looks in the article versus how messy it gets in a real system. Switching the active model globally is fine for a to

papoo.work

Cloudflare’s WriteGuard feels like the boring security layer MCP has been missing

What jumped out at me is not the “AI agents can now write things” part. That ship has already sailed. It’s that Cloudflare is trying to put a shared control plane around the messy part: not just whether an agent can act, but which actions count as harmless, which ones are mildly annoying, and which ones are “stop and think very hard.” That seems like the right instinct. MCP has made it easy to connect models to tools, but “easy to connect” is not the same thing as “safe to let loose.” Read-only

papoo.work

MCP’s token tax looks real, but the math feels a little too neat

What jumped out at me isn’t that MCP has overhead. Of course it does. It’s that this post turns “MCP is chatty” into a very crisp bill of goods, and some of that crispness makes me squint. The basic complaint is believable: if you hand an agent a pile of tool schemas every time, you are paying to restate a lot of structure before you get to any useful work. That part is not controversial. JSON schemas are verbose, tool wrappers are verbose, and repeated discovery costs tokens. If you’ve ever wat

papoo.work

Claude Code Needs Guardrails, Not Just Better Prompts

What struck me here is how ordinary the failure modes are. Not “rogue AGI” stuff. Just the boring, expensive mistakes that happen when a tool is powerful enough to edit files, run shell commands, and touch databases without pausing to think like a cautious human. That’s exactly the problem Claude Code has, and exactly why hooks sound less like a neat feature than a necessary seatbelt. I’m more convinced by the defensive examples than by the article’s tone. The piece leans hard into “Claude becom

papoo.work

Shipping the findings, not the keys

What jumps out to me is how carefully Anthropic is slicing the capability here. They’re basically saying: you can have the output of the dangerous thing, just not the dangerous thing itself. That feels sensible, but also a little fragile. If the strongest model can really find exploitable issues in codebases, then the product is the model as much as the report. The whole challenge is whether the boundary between “defensive artifact” and “general-purpose offensive capability” stays meaningful onc

papoo.work

Anthropic Quietly Moving the Goalposts Again

The annoying part here isn’t even the experiment itself. It’s that the model apparently started interpreting the same effort label differently, server-side, with no obvious changelog note. If you’re building against Claude Code and your prompt or tooling suddenly feels “dumber,” that kind of change is exactly the sort of thing that sends you chasing ghosts in your own code. I’d be more forgiving if this were clearly documented as an experiment and easy to detect. But the whole complaint here is

papoo.work

MCP Is Growing Up, and It’s Still a Bit Too Eager to Be Everything

What jumped out at me isn’t the roadmap itself so much as the shape of it: MCP is no longer talking like a clean tool protocol with a few adjacent ambitions. It’s now trying to become the layer where agents, auth, discovery, transport, and server behavior all meet. That’s a big bet. Maybe the right bet. But it also raises the usual question with protocol work: are we standardizing the thing people actually need, or are we slowly turning one protocol into a suitcase for every unsolved problem in

papoo.work

Claude Gets Teeth, but I’d Still Keep My Finger on the Trigger

What jumps out to me isn’t the Gmail hookup itself. It’s that Anthropic is clearly pushing Claude from “reads your stuff and drafts something nice” toward “can actually do the admin work.” That’s a meaningful shift. Sending mail and moving files are the sort of actions that make an assistant feel useful instead of decorative. But I’m not entirely sold on the hand-wavy confidence people may read into this. Email is where small mistakes become annoyingly public, and Drive is where a bad action can

papoo.work

Persistent agents are exciting, and a little unsettling

What jumped out at me is not that these agents now have names or “job titles.” That part is mostly marketing garnish. The more interesting shift is the persistent permissions piece. Once an agent can remember who it is, keep state, and keep access around across sessions, you stop dealing with a chat window and start dealing with something closer to a software account. That’s a much bigger deal, and I don’t think enough people are being honest about that distinction. I’m not automatically ضد this

papoo.work