New AI projects on Hugging Face or GitHub, May 27 2026. One repo shipped the precision replacement for yesterday's deletion.

Yesterday set up the problem

The previous day's piece walked through commit 787dbb33: 45 lines moved in ACPBridge.swift to delete a single constant called inactivityTimeout and the two waitForMessage call sites that passed it. The argument in the comment was protocol-level. The Agent Client Protocol defines exactly five ways a prompt turn can end and Timeout is not one of them. A blunt clock that fires on output silence cannot distinguish a slow model from a stuck process; a clock that fires anyway penalizes correctness.

That argument leaves an obvious hole. Real hangs happen. A Playwright MCP attached to a Chrome extension whose tab has died will sit on its tool call forever, ignoring the cooperative session/cancel that ACP defines. If the blunt timeout is the wrong answer, what is the right one? May 27 is the day that question got answered, in two commits, by one author, in a single file.

One day, six releases, in order

Walk the day top to bottom. The morning work is rescue. The afternoon work is the force-stop landing. The evening work is the cleanup the force-stop made obvious.

The stall detector, in the file the author edited

Commit 9ce9a77a, 15:33 PDT, adds 56 lines to acp-bridge/src/index.ts. Two constants and one setInterval. The constants are the spec this whole change works to:

// --- Stall detector ---
// Surface (but do NOT cancel) an in-flight `mcp__*` tool that has stopped
// emitting status updates for more than STALL_THRESHOLD_MS. A healthy slow
// tool keeps emitting in_progress / rawInput updates (lastUpdateAt
// advances); a wedged SDK→MCP forward goes silent (Playwright on a dead
// Chrome extension is the canonical case).
const STALL_THRESHOLD_MS = 15_000;
const STALL_CHECK_INTERVAL_MS = 5_000;
const stalledTools = new Map<string, { sessionId: string | undefined }>();

setInterval(() => {
  const now = Date.now();
  for (const [toolCallId, tool] of inFlightTools) {
    if (!tool.title.startsWith("mcp__")) continue;
    const silentMs = now - tool.lastUpdateAt;
    if (silentMs > STALL_THRESHOLD_MS && !stalledTools.has(toolCallId)) {
      stalledTools.set(toolCallId, { sessionId: tool.sessionId });
      sendWithSession(tool.sessionId, {
        type: "tool_stalled",
        stalled: true,
        toolName: tool.title,
        toolUseId: toolCallId,
        elapsedSeconds: (now - tool.startedAt) / 1000,
      });
    }
  }
  // resumed-or-gone tools clear via the same shape with stalled: false
}, STALL_CHECK_INTERVAL_MS).unref();

Three small choices in those constants do most of the work.

• 15 seconds, not 60. Most MCP tools that work emit at least an in-progress update every second or two. A genuine wedge is silent for tens of seconds before anyone notices. 15 is well above the noise floor and well below the "is this thing on" threshold a user feels.
• Per-tool, not per-turn. The map key is toolCallId; the "silence" that triggers the flag is silence on one specific tool call, not the whole turn. A slow model that is between tool calls does not trip anything.
• Informational, not enforcing. The detector emits a message and returns. It does not abort the query, does not call session/cancel, does not touch the subprocess. It only tells the UI what it sees.

The SIGKILL escape hatch, in one regex

Commit bd4bb69e, 16:12 PDT, adds 115 lines to the same file. The top half implements a process-tree walker. The bottom half uses it to find every descendant of the codex-acp parent whose command line matches a regex, and SIGKILLs them. The matching pattern is /playwright/. That is the whole filter. Everything is built on top of it.

function findDescendantsMatching(
  parentPid: number,
  cmdPattern: RegExp,
): Array<{ pid: number; command: string }> {
  const results: Array<{ pid: number; command: string }> = [];
  const visited = new Set<number>();
  function walk(pid: number) {
    if (visited.has(pid)) return;
    visited.add(pid);
    const out = execSync(`pgrep -P ${pid}`, { encoding: "utf8" }).trim();
    const children = out ? out.split("\n").map(Number) : [];
    for (const c of children) {
      const cmd = execSync(`ps -p ${c} -o command=`, { encoding: "utf8" }).trim();
      if (cmdPattern.test(cmd)) results.push({ pid: c, command: cmd });
      walk(c);
    }
  }
  walk(parentPid);
  return results;
}

function forceStopBrowserMcps(reason: string): { killedPids: number[] } {
  if (!acpProcess?.pid) return { killedPids: [] };
  const matches = findDescendantsMatching(acpProcess.pid, /playwright/);
  const killedPids: number[] = [];
  for (const { pid } of matches) {
    process.kill(pid, "SIGKILL");
    killedPids.push(pid);
  }
  return { killedPids };
}

Two trade-offs are documented in the comments. The first is honest about blast radius: the SDK does not expose which Playwright PID belongs to which session, so a force-stop in chat A may kill a Playwright subprocess that chat B was using. The author accepts that because the extension shares one Chrome anyway. The second is why this works at all. Once the subprocess dies, the SDK's MCP client sees the JSON-RPC transport close. The in-flight tool call returns an error to the agent loop instead of hanging forever, and the turn unwinds normally. The kill is what makes cancellation actually arrive.

Slow success vs. real failure, side by side

The argument for replacing the blunt timeout with these two mechanisms only lands if the new instruments draw a clean line where the old one drew a smudge. They do. The signals are different, the timing is different, and the user-visible behavior is different.

Six releases, in seven hours

Five other releases hit the App Update channel between v2.9.41 and v2.9.46 the same day. None of them carried the force-stop work, but every one of them is a window into how the project treats shipping: a release is the unit of one named fix, not the unit of a marketing decision.

v2.9.45, the force-stop release, is highlighted. Cut times are Pacific, sourced from the corresponding "Release changelog for v..." commits in the public log.

Why the previous day's argument needed today's code

The May 26 deletion was defensible at the protocol layer. ACP has no Timeout stop reason; a loop-wide wall clock invents one and penalizes the only signal it has, which is total output silence. A slow model goes silent for the same reason a stuck process does: no bytes on the pipe. The blunt cure could not tell them apart.

But removing the cure without a replacement leaves the actual stuck case worse, not better. A Playwright tool call that hangs against a dead Chrome extension would simply hang forever, because ACP's session/cancel is cooperative and the wedged call has no event loop to receive it. The May 27 work closes that gap by looking at the right signal: not loop-wide silence, but per-tool silence. A tool call that has stopped emitting updates for longer than 15 seconds while everything else is fine is a much better wedge detector than total output silence on a 600-second clock.

And when the wedge is real, the kill is unilateral. There is no polite Stop sent to the subprocess. The SDK does not expose a sane handle. The process tree gets walked, the regex gets matched, the kill arrives. Once the JSON-RPC pipe drops, the in-flight tool errors back to the agent and the turn unwinds. The two commits together are the answer to a question the previous day opened: what should happen instead of a clock.

How to read any project's real May 27

The same recipe works against any other GitHub project that catches your eye. Open the changelog. Read the entries dated 2026-05-27. Pick the one whose headline sounds load-bearing. Open the commit log between midnight and midnight on that date, ignore the merges, and find the commit whose subject matches the headline. Run git show --stat <hash> to see which file moved and by how much. If you only read one file, read the one with the largest delta. If you only read one section of that file, read the comment that introduces the change, not the commit message; the comment is what the author wrote for future readers, the commit message is what they wrote for the history.

A daily roundup tells you what existed at the end of the day. A commit log tells you what the maintainer was thinking, hour by hour, in the order they thought it. The two are not interchangeable. On May 27 the maintainer was thinking about how to replace a timeout with something that watches the right thing. The roundups will not show you that. The commits and the file will.