[nedtwigg]

Clicking into an idle Claude Code pane rang a false "claude went quiet" once you left. The click sends a focus report (ESC[I), and Claude answers by repainting real text. In one report the repaint began 1.4 s after the click and lasted 1.8 s. The output/silence detector read that as work, so when the user moved away the settle rang. Two diagnostic reports (2026-10-19, surface:12 and surface:42) show the same sequence: click, repaint, leave, ring.

The rule: a busy run must begin within cfg.alert.workStartWindow (5 s) of either:

• input: any PTY write except a terminal reply or a mouse report, which includes keys, a paste, a Client, dor send and launches;
• an active OSC 9;4 report, so a turn Claude starts by itself (a background task waking it, /loop) still reads as busy and still defers a ring it owes.

Output that would start a run later is ignored entirely, the way echo is: a repaint on focus or resize, or a status-line tick. Once a run has begun, all of its output counts until it settles.

• One write hook. AlertManager.onWrite(id, data, { userInput }) hears every PTY write before it reaches the PTY: it acknowledges human input and opens the work-start window. alertedPty.write (both hosts and Pocket's Burrow path) and FakePtyAdapter.writePty call it instead of their copied prologues.
• Classification. inputCanStartWork in terminal-report-filter.ts reads a chunk the way the renderer's input branch does. It returns early on a write that doesn't start with ESC, so a large paste never goes through the regexes.
• Resize grace deleted. The gate covers what the 500 ms grace after each resize covered. QuiesceDetector.onResize, AlertManager.onResize, alertedPty.resize and cfg.alert.resizeDebounce are gone, and the hosts resize the PTY directly.
• A wheel tick is input. A third report (2026-10-21, surface:164) was a wheel scroll through Claude Code's transcript, which repaints for as long as the scroll lasts. A wheel report sent to the program now acknowledges as user input, like a keystroke, locally and from a Client. It never opens the work-start window, because scrolling asks for no work: a repaint trailing the scroll, or a status-line tick after it, is still ignored. It also leaves a finalized selection alone, as a scroll did before. Hover, drag-motion and button reports stay passive; a click acknowledges through the Pane. stripPassiveMouseReportsFromInput in terminal-report-filter.ts draws the line, and inputCanStartWork takes userInput so that a human's reply-shaped key (Shift+F3) still starts work while a wheel tick doesn't.
• Spec. docs/specs/alert.md → WATCHING Track states the rule. The rationale records the reports and the cost.

Behavior changes:

• Scrolling a program that asked for wheel reports acknowledges it with input. It clears the ring and the TODO, as typing does. That includes a scroll from Pocket.
• Output nothing asked for no longer forgets an acknowledgement or cancels a --until quiet grace window. So a repaint after a click doesn't turn a stale idle ping into a fresh ring, and an await on an idle Session resolves idle instead of being kept parked by a repaint.
• A watched command whose first output comes more than 5 s after Enter never reads as busy. The default watch list (claude, codex, pi) starts output at once.
• Output that resumes after a mid-run settle, with no input or OSC 9;4 report inside the window, is ignored too. An owed ring stays up through it, and a later await resolves on that ring. Letting an owed ring reopen the gate would bring back a resize or status-line repaint hiding a ring that is already showing. The default agents keep a spinner going through a turn, so they never settle mid-run.

Tests:

• New tests cover the gate in the detector and the field scenario through alertedPty:
  • a click, a focus report and a 2 s repaint, then leaving, never rings;
  • dor send followed by work rings;
  • a progress report with no input defers an owed ring;
  • a userInput write that looks like a reply (Shift+F3, ESC[1;2R) still starts work;
  • inputCanStartWork unit cases.
  • wheel reports in SGR, URXVT and X10 encodings, with modifiers, acknowledge as keystrokes; hover and button reports don't;
  • scrolling an idle program for 3 s while it repaints never rings, nor does a repaint that starts 1.5 s after one tick and lasts 2 s;
  • a wheel tick leaves a finalized selection alone;
  • a Client's wheel report acknowledges, while its tap or hover report doesn't.
• Each new test goes red with its line deleted.
• Existing tests now give the program input before its work, through shared press / work helpers in alert-manager-test-utils.ts. The website's alert-program tests type through FakePtyAdapter.writePty, the way the playground does.

Verified locally:

• lib: 6028 passed, plus tsc -b.
• website: 448 passed.
• vscode-ext: 229 passed, plus tsc.
• standalone: 296 passed, plus tsc.
• The spec lint passes.

🤖 Generated with Claude Code

[cloudflare-workers-and-pages]

Deploying mouseterm with    Cloudflare Pages

Latest commit:	51c38e3
Status:	✅  Deploy successful!
Preview URL:	https://c02dcf93.mouseterm.pages.dev
Branch Preview URL:	https://alert-input-gate.mouseterm.pages.dev

View logs

[dormouse-bot]

One thing to decide before this merges, inline on the gate: output that resumes after a mid-run settle is now ignored once it falls outside the work-start window.

Separately, a one-line leftover outside the diff: the alertedPtys doc comment in vscode-ext/src/message-router.ts still reads "Every PTY write and resize, as the alerts must see it." alertedPty no longer handles resizes.

[dormouse-bot]

The wheel-as-input commit gives a scroll the same false-ring path a click had, and it also changes what a scroll does to a selection. Details inline.

Superseded by the review on a later commit.