New AI projects on Hugging Face or GitHub, May 16 2026. Pick one release, open the patch, and the question answers itself.

One release. Two commits. One specific bug.

Two commits authored on May 16, 2026, sitting next to each other in the git log. The first, 3ceb252b at 08:59 Pacific, edits a Swift file in the macOS app. The second, 102b4f97 at 09:20 Pacific, edits a TypeScript file in the Node sub-process that talks to the agent. They land together because they fix the same underlying bug from opposite ends of the wire.

The bug is the kind that does not appear in a feature list. Pop-out chat windows were losing their conversation history when the working directory changed between turns. An ordinary user-visible symptom: you send a follow-up message, the model replies as if it has never seen the conversation before. The actual cause is two layers down, in how a per-window workspace defaulted, and what that default did to the cwd sent to the agent bridge.

The Swift side: anchor the cwd at creation

The pop-out chat window stored its workspace in a per-window struct. When the field was empty, the code "fell back" to a global setting called aiChatWorkingDirectory. That global is what the main chat window writes when the user picks a project folder, and it changes every time the user switches projects. Two pop-outs open at the same time would both read the same global, which meant each one's effective cwd flipped whenever the user picked a different folder in any window. Every flip tore down the upstream session.

The Swift fix is six lines. At pop-out creation, if the per-window workspace is empty, fill it with NSHomeDirectory() so the cwd is explicit and sticky from the first turn. Every pop-out then carries its own workspace for the rest of its life.

That alone stops new pop-outs from drifting. It does not help the existing ones, because the conversation has already been written to disk under one cwd and the SDK is about to look for it under another. That is what the TypeScript side handles.

The TypeScript side: relocate the transcript

The Claude Agent SDK persists every turn of a session as one line of JSON, appended to a file named for the session id, stored under ~/.claude/projects/<encoded-cwd>/<sessionId>.jsonl. The directory name is the working directory the session was created in, percent-encoded so it can sit in a filename. When you call session/resume, the SDK looks under the encoded directory derived from the cwd you pass at resume time. If the cwd changed since the session was created, the SDK looks under a directory that does not contain the transcript, finds nothing, and either errors out or starts a fresh session.

The fix is to physically copy the JSONL into the new workspace's encoded directory before resuming. The new function does exactly that, and nothing more. It is one function call in the cwd-changed branch of the query handler. The comments in the diff are longer than the implementation.

Two guard rails are worth pointing out. The function refuses to touch anything that is not under ~/.claude/projects, so a Codex rollout (which is date-bucketed, not cwd-addressed) is never moved. The copy is followed by an unlink that is wrapped in a try/catch, so a partial failure still leaves a usable transcript at the destination. The caller falls back to the older priorContext replay path on any failure, so the worst case is a capped summary rather than a dropped conversation.

Why this one patch is the answer to a feature claim

"Persistent sessions" and "no auto-compacting" are easy phrases to put on a landing page. They are hard to deliver, because the place they break is exactly here: the moment a user does something the original session was not opened for, like switching to a different project folder mid-conversation and asking a follow-up. Every workspace switch is a hostile test of the persistence claim, and most implementations fail it quietly.

The May 16 patch is what passing that test costs. A few kilobytes of TypeScript that knows the layout of the Claude Agent SDK's persistence directory, a Swift change that gives every pop-out its own sticky cwd, and a fallback path that degrades to a capped summary rather than an empty context. None of that is visible to the user. All the user sees is that the follow-up question still gets a coherent answer. That is the only acceptable outcome.

Open the diff and you can see exactly which line is doing the work. That is the difference between a feature page and a patch. A feature page tells you what the project would like to be true. A patch tells you what is actually shipping.

Three files to read for any project that catches your eye

The exercise generalizes. For any new project surfacing on Hugging Face or GitHub on any given day, the same three artifacts give you a faster read than any roundup. Open them in order; each step is about thirty seconds.

If the changelog is empty, the commit log is one launch commit, or the diff has no inline comments, you are looking at a project that has not yet earned the trust the trending list is granting it. The single release on 2026-05-16 passes all three checks. That is the only reason a dated query is worth answering with one release instead of a list of ten.

What "release cadence" looks like at the day scale

One release on May 16, four on May 15, three on May 14, two on May 13, two on May 12, three on May 11. Then zero on May 17, the day this guide was written. That bumpy line is the shape of a project that ships when it has something to ship and not when it does not. A press-release rhythm of one launch per month would be a worse signal, not a better one.

The texture matters more than the count. The May 16 release is a single bug fix authored two hours after the engineer started looking at the bug, with comments that name a global variable and a fallback path. That kind of patch can only come from a project that has real users hitting real edges. It is uninteresting to a feed and exactly what you want a dependency to look like.