v2.8.1: Long Instruction Files Stop Breaking Employees, Your Gmail Arrives With a Name, and WebSocket Functions Run 50 Times Faster

A patch release with one dramatic number in it, one bug that had been quietly killing individual employees, and a gap we left open in the last release and have now closed.

Employees with very long instructions start up again

If one of your Claude employees suddenly stopped working entirely, this was probably why. Once an employee's CLAUDE.md grew past 128 KiB, every session failed the moment it launched. The chat showed read EIO and a missing terminal buffer, and nothing you did to the file helped, while every other employee on the same instance carried on perfectly.

The cause is a Linux limit rather than anything clever. We passed the entire contents of CLAUDE.md to Claude as a single command-line argument, and Linux caps one argument at 131,072 bytes. Below that, fine. Above it, the process simply cannot start.

The employees hitting this are the diligent ones. If your employee appends a note to its own instructions after each session, it crosses that line in a few months of real work. The case that was reported to us was 146,215 bytes, with 129 KB of it in a single project section.

We now hand Claude the path to the file instead of its contents. Identical instructions, no size limit. Affected employees recover as soon as your instance runs this release, and you don't need to trim anything.

Your Gmail messages now arrive with a name on them

Email sent through the Gmail skill was reaching people as a bare address. No name, just [email protected] sitting in the From line, which looks like a mailing list at best and a phishing attempt at worst.

Messages now go out as Name <address>, using the display name of the connected Google account. Names with accents are encoded properly, so "Chloé" arrives as Chloé rather than as a row of symbols. If you want something different, send, reply and draft take a --from-name option, and passing an empty one gives you the old bare address. Replies and drafts behave the same way, including a draft written today and sent next week.

You don't have to do anything: existing employees pick up the account name straight away.

Google and Microsoft 365 now genuinely work on Community Edition

In v2.7.24 we opened the Google and Microsoft connectors to Community Edition. We left something out. You could connect the account, the panel said everything was fine, and then every command the employee actually ran (Gmail, Calendar, Drive, Docs, Sheets, Slides, Forms, Outlook, OneDrive, SharePoint, Word, Excel, PowerPoint) came back with 403 EE feature.

The connector was open; the routes behind it were not. Seventy-one of them, including account listing and Gmail attachment downloads. They're open now, connector status no longer claims Google and Microsoft 365 are unconfigured, and incoming Gmail and Outlook notifications are processed on Community Edition too.

Microsoft Teams, the Desktop App and the Enterprise skill sync remain Enterprise features, along with the other connectors listed in v2.7.24.

We said last week that a rule written in several places drifts out of sync. This is the same lesson arriving by return of post: we moved the connector rule into one place and left the route rule where it was.

Office 365 can send from an alias

The Office 365 Mail skill always sent from the mailbox's primary address, even when the account was allowed to send from an alias or a shared mailbox. Worse, when Exchange refused something, all you got back was "Failed to send email", which tells you nothing.

send, reply and draft-create now take --from and --name. When you set a sender, the message carries it, and Exchange decides whether your account is allowed to use that address. If it isn't, you now see exactly what Microsoft said, for example ErrorSendAsDenied: The user account which was used to submit this request does not have the right to send mail on behalf of the specified sending account. An error you can act on beats a polite one you can't.

One honest limitation, which is in the skill documentation as well: the display name isn't yours to choose. For an alias, Exchange keeps the mailbox's own name no matter how you ask, including through a raw message with its own header. If you need to send reliably under a different name, that needs a shared mailbox with Send As permission. We tested this properly before writing it down, and a real authorised Exchange alias is the one case our test tenant couldn't cover.

WebSocket functions went from 2 messages a second to 106

This is the number worth reading twice.

Web Publish shipped WebSocket functions in v2.8.0. They worked, and they were slow enough to be useless for anything live: roughly two messages per second. Every single event started a fresh sandboxed Node process, about 100 ms of it, and every database call started another process on top, about 40 ms more. Module-level state was thrown away between events, so a function that set up its schema "once" was running CREATE TABLE on every message.

A connection now keeps one warm worker for its lifetime. The function loads once, every event for that connection runs in the same process in order, and variables you set at module level stay set. Activate a new version and the next event picks it up with fresh state. Close the connection and the worker stops. A crash or a timeout restarts it on the next event. Past a configurable ceiling (256 warm workers by default) events fall back to the old one process per event behaviour rather than failing.

The database side moved too. SQLite now runs inside the function process, HTTP calls included, with the same validation and limits as before, and it sets its busy timeout first, so two workers on the same project can write at the same time instead of colliding with database is locked.

The measurements, since claims like this deserve them: a warm invocation running three SQL statements takes about 6 ms, against 220 ms spawned. Over the public connection, one client had 300 moves acknowledged in order at 106 messages per second from a single worker. Two clients at once got 84 and 85 each. In a closed loop straight to the backend the median response was 8 ms, and through Cloudflare it was 36 ms, which is the network trip rather than the runtime. Two browser tabs each firing 60 moves a second kept up, with an average round trip of about 145 ms from Israel.

That's the difference between a demo and a multiplayer game that is actually playable, which was the point of the exercise.

Want to test the most advanced AI employees? Try it here: https://Geta.Team