Root cause

User report: typing regular letters/numbers in Chrome with a Cotabby suggestion visible silently drops the character. Three subagent investigations converged on the same structural cause introduced by #337 (split-tap model):

The active accept tap (.defaultTap, tail) returns nil and swallows any keystroke whose (keyCode, modifiers) matches the user's bound accept binding. The matching is correct in isolation, but:

• KeyRecorderView accepts and stores any keycode the user presses, including bare alphanumerics. (keyCode: 0, modifiers: []) is a valid stored binding meaning 'a'. From that moment every bare 'a' in any app while a suggestion is visible is eaten.
• The default full-accept binding is bare backtick. Users type backticks regularly.
• The matching uses providers read at event time. There is no in-the-moment check that a real, ready, valid session exists when the tap consumes.

Fix (two layers, both fail-open)

1. Bare-printable safeguard. In handleAcceptTap, if the binding match would fire for a keystroke that has no modifiers and produces a non-control printable, refuse to consume and warn in the log. Acceptance via a bare letter is incoherent (the same press cannot both insert the user's character and trigger acceptance).
2. Coordinator authorization. New shouldConsumeAcceptKeyProvider closure on InputMonitor. The coordinator wires it to a live check: state == .ready AND interactionState.activeSession != nil AND overlayState.isVisible. The tap only consumes when all three hold at event time. Any stale install, lifecycle gap, or settings race collapses to pass-through.

Plus debug logging on every consume decision so future swallow reports can be diagnosed from the runtime log.

Why this prevents the symptom

• A corrupt bare-letter binding can no longer eat typing — Layer 1 catches it.
• A stale active tap surviving past a session invalidation can no longer eat typing — Layer 2 catches it.
• The legitimate acceptance path is unchanged: when state is .ready, the session is live, and the overlay is visible, the predicate returns true and the bound key is consumed as before.

Test plan

1. Repro the swallow: bind bare 'a' in Shortcuts, type 'a' in Chrome with a suggestion visible. On main the character disappears. With this PR it reaches Chrome and a warning lands in the runtime log.
2. Backtick: leave default binding, type code containing backticks in Chrome with a suggestion visible. On main the backtick disappears. With this PR it reaches Chrome.
3. Stale-session race: prime a state where the overlay is briefly visible but state has flipped to .debouncing. The accept key now falls through instead of being consumed.
4. Regression: bind ⌃Tab, generate a suggestion, press ⌃Tab. Acceptance still fires and the keystroke does not reach the host.
5. Build + lint clean.

Risk / rollout notes

• Fail-open by design. The worst case for the fix is that a legitimate accept key is occasionally passed through — the user sees their key reach the host instead of accepting the suggestion, which is the safe failure mode.
• shouldConsumeAcceptKeyProvider defaults to { false } on InputMonitor, so any test or future call site that constructs the monitor without wiring the coordinator will pass keys through rather than swallow.
• This does not address the duplicate-Tab bug Agent 3 flagged in passTabThrough's unconditional replay. That is a separate PR.

Greptile Summary

This PR adds two fail-open guards to the active accept tap: Layer 1 refuses to consume keystrokes whose binding has no modifiers and produces a printable character, and Layer 2 delegates the consume decision to a new shouldConsumeAcceptKeyProvider closure wired in SuggestionCoordinator to a live three-condition predicate (state .ready + active session + visible overlay).

• InputMonitor.swift: handleAcceptTap gains the two guard layers and structured debug/warning logging for every consume decision.
• SuggestionSubsystemContracts.swift: shouldConsumeAcceptKeyProvider: @MainActor () -> Bool added to SuggestionInputMonitoring, defaulting to { false } on InputMonitor so stale installs are automatically fail-open.
• SuggestionCoordinator.swift: The provider closure is wired at init time before any overlay callbacks, using [weak self] so deallocation also collapses to false.

Confidence Score: 3/5

The two-tap architecture means the observer tap always drives acceptance independently of what the accept tap subsequently decides — Layer 1 prevents consumption but cannot un-do the acceptance already triggered by the observer for the same event.

The Layer 2 wiring is correct and the fail-open default is safe. Layer 1's bare-printable guard creates an observable double-action for any user with a misconfigured bare-printable binding: the observer tap classifies the keypress as .acceptance and drives suggestion insertion before the accept tap even runs, so acceptance happens AND the character reaches Chrome. Additionally, in the normal acceptance success path the observer hides the overlay (updating overlayState) before the accept tap fires, so Layer 2 reads overlayState.isVisible = false — whether this causes the accept key to leak to the focused app depends on undocumented CFMachPortInvalidate in-flight semantics that should be validated empirically.

Cotabby/Services/Input/InputMonitor.swift — both the Layer 1 guard in handleAcceptTap and the Layer 2 overlayState timing need a second look before merge.

Important Files Changed

Sequence Diagram

sequenceDiagram
    participant User
    participant macOS
    participant ObserverTap as Observer Tap (head, listen-only)
    participant Coordinator as SuggestionCoordinator
    participant AcceptTap as Accept Tap (tail, active)
    participant Chrome

    User->>macOS: keyDown (accept key)
    macOS->>ObserverTap: event delivered (1st)
    ObserverTap->>Coordinator: classify → onEvent(.acceptance)
    Coordinator->>Coordinator: acceptSuggestion()
    Note over Coordinator: Guards: session≠nil, state==.ready, overlay visible
    Coordinator->>Coordinator: insert suggestion text
    Coordinator->>Coordinator: hideOverlay → destroyAcceptTap()
    ObserverTap-->>macOS: passUnretained (always)

    macOS->>AcceptTap: event delivered (2nd)
    Note over AcceptTap: Layer 1: isBarePrintable?
    alt "isBarePrintable == true"
        AcceptTap-->>macOS: passUnretained (key NOT consumed)
        macOS->>Chrome: key delivered
    else "isBarePrintable == false"
        Note over AcceptTap: Layer 2: shouldConsumeAcceptKeyProvider()
        alt session ready + active + overlay visible
            AcceptTap-->>macOS: nil (key consumed)
        else any condition false
            AcceptTap-->>macOS: passUnretained (key NOT consumed)
            macOS->>Chrome: key delivered
        end
    end

_{Reviews (1): Last reviewed commit: "Fail-open accept tap: never consume bare..." | Re-trigger Greptile}

Greptile also left 2 inline comments on this PR.