Daily Edition Sources +6

The Allow Button Was Waiting for a Socket

OpenWork reproduced a ten-second approval timeout before the user’s decision reached the engine. The repair gives that decision a separate route through a busy desktop app.

A marker diagram shows a desktop permission reply taking a separate HTTP route past event-stream socket pressure to the local engine.
Diagram Punka human decision needs a route through the busy app. The proof covers the tested local path.
repo different-ai/openwork evidence
6 source signals 1 repo 6 source signals
Evidence: 6 source signals / September 17, 2026 / Daily Edition
Open Edition Evidence below

The user has already decided. They click “Allow once,” giving an agent permission to read a folder. Ten seconds later, the permission card is still there, accompanied by a timeout. In a regression test added to different-ai/openwork on September 16, the model is not taking too long to think. The approval request never gets onto the wire.

That is a peculiar failure for a product built around supervising software agents: the interface can ask for a human decision while the transport beneath it cannot deliver the answer. OpenWork merged a targeted desktop fix that evening. Permission replies now take an isolated local HTTP path instead of waiting behind the renderer’s event streams.

The conversation occupied the road

Agent interfaces keep connections open to receive events as work happens. Those streams carry progress, tool activity and new messages. On the inspected Electron path, long-lived HTTP/1.1 streams competed for Chromium’s per-origin connections with short requests such as a permission reply. The display could remain responsive even while another network request waited for space.

The project’s public investigation separates that mechanism from a reported installed-app incident. In the controlled baseline, event-stream pressure kept the approval pending until its ten-second deadline; independent engine reads still succeeded. Removing only the artificial pressure let the same permission complete. The report does not establish that the installed incident had the same cause: that application was not instrumented.

The stronger test comes next. After the local engine accepts the reply, the requested read finishes while the fixture deliberately withholds the model’s final answer. Another session’s permission remains pending. This checks two things a spinning button cannot tell a user: their answer reached its intended request, and acknowledging it did not require another inference call.

The pull request reports an approximately 55-millisecond pressured click on its final tested head, compared with the baseline timeout. Those are measurements from the project’s isolated Electron fixture, not a promise about everyone’s desktop or model speed.

A bypass with boundaries

The client change identifies finite permission-reply POSTs and sends them through the existing main-process transport. The local HTTP helper uses Node networking for exact plain-HTTP loopback addresses. Merely moving a request into another Electron process would not be enough if it still used networking subject to the same Chromium pressure.

The selection is narrow. Event streams remain on their native path. External and HTTPS requests retain Electron’s trust and proxy behavior. Allow once, Allow for session and Deny keep their existing meanings; the patch changes how the reply travels.

Cancellation matters as much as speed. Both sides of the desktop transfer recognize permission replies, preserving deadlines and caller cancellation. But closing a request cannot undo a permission the engine has already applied. A timeout is therefore not proof of rejection, and the fix does not automatically replay the decision.

We ran the repository’s eight standalone finite HTTP transport tests; all passed. They exercise reply bodies, cancellation while headers or bodies are held, HTTP errors without replay, redirects and address boundaries. We inspected, but did not rerun, the full Electron pressure scenario.

The next control can still be stuck

This patch does not reduce the number of event-stream subscriptions. Nor does its pressure proof cover every send, question form, metadata write or complete Stop operation. The test checks Stop cleanup after pressure is released; that is not evidence that the whole Stop path has gained the same isolation.

OpenWork’s latest listed release at our September 17 check, v0.18.48, was published September 15, before this merge. Users should not infer that an installed build already contains the repair.

For builders, the consequence is broader than this button: a supervision control needs transport capacity when the conversation is busiest. Test the decision’s arrival separately from the work it unlocks, and preserve uncertainty when an acknowledgement disappears. The next useful proof from OpenWork is that the remaining controls can get through under the same pressure—or that the stream budget no longer creates the traffic jam.

Evidence Trail

Receipts below the story

The article above is the public narrative. This section keeps the source trail and limits on the same page.

Edition
DateSeptember 17, 2026
LaneDaily Edition
Confidence87%
Sources6
Reposdifferent-ai/openwork

Primary Evidence

Evidence Limits

  • The controlled reproduction does not establish the installed incident cause. Timing comes from the project fixture. We ran standalone transport tests, not the full Electron pressure scenario. The patch does not certify all controls under pressure or reduce stream subscriptions. A timeout cannot undo an accepted reply. A merge is not proof of installed availability.
Letters & Corrections

Send a note to the desk

Corrections, missing context, or a follow-up lead.