Why chats said "Connection lost", and the fix

On 20 October, our own 5.0.0 install started misbehaving. The computer we were sitting at showed up as "not reached", blinking on and off. The window reloaded itself every few minutes. Chats said "Connection lost". Worst of all, agents that were in the middle of work stopped.

If you saw any of that on 5.0.0, this is what happened, what fixes it, and what to do until you have the fix.

The short version#

One very long chat couldn't be loaded. Every attempt froze Shuriken's background service (the part that keeps your agents running with the window closed) for several seconds and ballooned its memory. Your apps, which follow the agents running on that computer, read the freeze as "the computer is gone", and the service's own watchdog restarted it. A restart ends every running agent. Then the app tried to load the chat again.

The fix shipped in 5.1.0: long histories load in steps with bounded memory, and the service protects itself before it runs out.

What actually went wrong#

Some chats get big. A long Claude Code session with plenty of subagents can leave well over a hundred thousand events in its history. That's fine on disk. The trouble was in how 5.0.0 read it back.

The stack overflow. The history loader added events to a list with one call that passed every event as a separate argument. JavaScript allows a lot of arguments, but not unlimited: somewhere past roughly a hundred thousand (the exact number depends on the engine) it throws "Maximum call stack size exceeded". The chat with roughly 120,000 replayed subagent events hit exactly that. Nothing was wrong with the chat. The read itself couldn't hold it.

The freeze. Each attempt took around 20 seconds, pushed the service's memory from about 2 GB to over 4 GB, and paused it for 10 to 14 seconds at a time while memory was cleaned up.

The domino. Every liveness check in Shuriken runs inside that same service: the heartbeat to your apps, the link to our cloud, the watchdog that restarts a stuck service. A 14-second pause looks exactly like a dead machine. So your devices showed "not reached", windows reloaded, and the watchdog did its job and restarted the service. On 20 October that happened 18 times on the machine we diagnosed.

And because the app kept retrying the chat, the loop never ended on its own.

The fix in 5.1.0#

We fixed the cause and the blast radius separately, because the next huge thing won't look like this one.

• History is added one event at a time, never as one giant argument list. That removes the stack overflow outright.
• Long histories load in steps that hand control back. The transcript is read, replayed and stored in pieces, so the service keeps answering while a big chat opens.
• The service watches its own memory. Past 80% of its limit, the coldest sleeping chats (next point) give their memory back (they reload when you open them). Past 90%, a new load of a stored chat is refused instead of taking the service down. One chat that won't open is much better than every chat stopping.
• Idle chats sleep. A chat idle for 20 minutes frees its memory and wakes with its history on your next message. Running, waiting and queued chats stay awake. You can change the time or turn it off in Settings › Chat.

In the 5.1.0 notes this is half a line: chats "no longer get stuck on 'Connection lost', the background service no longer runs out of memory". Now you know what's behind it. The rest of the release is in the Shuriken 5.1 post.

If you're still on 5.0.0#

1. Leave the long chat on every device where it's open: click any other chat.
2. Quit Shuriken and open it again.
3. Don't open that chat again until you have 5.1.0. Your other chats are fine.

Agents that were running during one of the restarts stopped mid-turn. Their chats are intact; send a message to pick up where they left off.

What we changed in how we test#

Our tests used realistic chats. Realistic turned out to be too small.

We now keep two tests built around huge histories. One recreates a chat with more than 120,000 replayed subagent events: it fails on 5.0.0's code with the same error and opens on 5.1.0. The other opens a 50 MB Claude Code transcript and fails if the service ever pauses for a full second while doing it. Both are now part of our test suite, so this shape of chat can't quietly come back.

The lesson we're taking: whatever a person can do for a long time, someone will do for a very long time, and that's the case to test. We found this one on our own machine. If you hit something like it, report a bug from the top bar with a screenshot, and "What's new" will tell you when it's fixed.

The fix shipped in 5.1.0; on 5.0, the app offers it in its update window. New here? Try Shuriken.