fix(hook-server): a confirmation-gated control request must not be killed by the receive-phase timeout

[eneskirca]

Reproduction

An agent issues a canvas-control write to another node. The user takes more than 2 seconds to answer the confirmation dialog. The shim reports:

control endpoint unreachable

curl exits 52 (empty reply from server) at ~2019 ms — while the dialog is still on screen. A late confirm STILL delivers the text. So the agent is told the endpoint was unreachable when the write actually landed, and may retry: silent duplicate delivery. Stacked confirmations wedge agent messaging entirely.

The cause is that the hook server's 2 s slowloris guard (req.setTimeout(SLOWLORIS_MS, () => req.destroy())) was armed for the whole request lifetime, not just the receive phase. A destructive /control/ verb parks in the renderer by design, up to the desktop's 120 s pendingControl bound (src/main/index.ts) — far past 2 s.

The fix

The guard is a RECEIVE-phase guard: it exists for a client that dribbles bytes to pin a socket, not for the handler. So once the body is fully read, both the /control/ and /context-link/ routes hand the socket off from the guard to a much larger ceiling.

Why a bounded ceiling, not setTimeout(0)

Removing the ceiling outright would be a real behavior regression in two places:

• /control/ would then be bounded only by pendingControl's 120 s — a bound that lives outside core, in the desktop shell. A future core-side control handler would silently inherit an unbounded socket.
• /context-link/ would get no bound at all. handleContextLinkRequest has no timeout of its own, and its remote leg reads over an SSH ControlMaster that can wedge (ConnectTimeout only covers the connect). Pre-fix, the 2 s destroy at least unblocked the agent's curl; with no ceiling the agent's session blocks indefinitely — a worse failure than the one being fixed.

So:

• CONTROL_CEILING_MS = 130_000 — a named constant sitting comfortably above the desktop's 120 s bound, so in practice the handler's own timeout always wins and this only ever fires as a backstop. Applied to both routes. A confirmation-gated handler may legitimately park; nothing may park forever.
• /context-link/ additionally races its handler at 30 s (CONTEXT_LINK_READ_MS), resolving to the existing "Could not read linked context." string. The race is the effective bound there; the socket ceiling is only the backstop behind it. The helper also swallows a rejection — it must, or a read that rejects after the timeout already answered surfaces as an unhandled rejection — which as a side effect turns a rejecting handler into that same prose failure instead of a bare 204.

Test

src/core/agents/hook-server.slowloris.test.ts spins the real hookServer (same harness precedent as context-link.cli.test.ts) with handlers that park 3.5 s — past the 2 s guard — and asserts both routes still answer 200 with their payload.

Verified by stashing the production change:

• without the fix: 2 failed — TypeError: fetch failed / SocketError: other side closed (UND_ERR_SOCKET) on both routes
• with the fix: 2 passed

Gates

• npm run typecheck — clean
• npx vitest run src/core/agents src/core/context-link.cli.test.ts src/main/canvas-control-core.test.ts src/main/canvas-control-shim.test.ts — 13 files, 172 passed
• npx vitest run — 396 passed / 1 failed (398 files), 5114 passed / 3 failed (5129 tests). The 3 failures are all src/main/node-pty-patch.test.ts, environmental in this clone (symlinked node_modules); confirmed identical on the untouched tree at origin/main.

---

This carries the fix half of #113, with credit to @austinschneider (Co-Authored-By on the commit). That PR's agentSeamlessWrites setting and its Canvas write-path bypass are not included here — that half is being redesigned separately. #113 is left open for the owner; our fork policy is fast-forward-only on contributor branches, so the fix half is landed here rather than by rewriting theirs.

🤖 Generated with Claude Code