Desktop app: typed key events duplicate (paste duplicates too), plus completed UI rows blink forever

Still present on a much newer build, with two data points that complicate the preload theory.

Environment

• Claude desktop 1.40609.0 (this report: 1.34493.1)
• Bundled claude-code 2.1.247 (this report: 2.1.237)
• macOS Darwin 25.5.0, Apple M5, Australian layout, internal keyboard only
• hidutil property --get UserKeyMapping → (null); no remapper process running; single app instance (one main process, one set of helpers)

Occurrence

Cold launch at 05:32:04; doubling was already happening in the prompt composer by ~05:34, so it does not need a long-running app to develop. Purchase arrived as PPuurrcchhaaee.

Two differences from the original report:

1. It self-cleared. After a few minutes the doubling stopped on its own — no restart, no window close, no setting changed. Since a full restart is recorded here as not clearing it, the broken state appears able to resolve spontaneously as well as persist, which argues against a renderer that is permanently wedged.

1. No preload failure anywhere near this occurrence. ~/Library/Logs/Claude/unknown-window.log covers 2026-08-30 16:50 → 2026-08-31 05:32 and contains exactly one Cannot destructure property 'preloadScripts' of 'binding.startupData' as it is null pair, at 2026-08-30 19:43:45 — about 10 hours earlier and in a previous app run. Zero occurrences during, or in the hours before, the doubling. So the doubling can occur in a renderer whose preload initialized normally; the preload signature may accompany some occurrences but is not necessary for it.

Confirming the NSAutomaticPeriodSubstitutionEnabled observation — doubled spaces came through as . , so typed text looks mangled beyond a straight character doubling and the periods are a red herring.

Same fault on a much newer build, plus three observations that I think refine the cause here.

Environment

• Claude Desktop 1.49585.0, bundled claude-code 2.1.260 (yours was 1.34493.1)
• macOS 26.5.2 (25F84), arm64, 64 GB
• hidutil property --get UserKeyMapping → (null); no Karabiner / BetterTouchTool / Keyboard Maestro / Hammerspoon; InitialKeyRepeat and KeyRepeat at system defaults; single app instance

Your core report reproduces exactly: key event duplication, app-wide across the Code tab and ordinary chat windows, while every other application types cleanly at the same instant. Your note that NSAutomaticPeriodSubstitutionEnabled rewrites the doubled space as . also matches — that is precisely how it presents.

---

1. It self-recovers mid-sentence, with no restart, under heavy system load.

Twice, doubling stopped partway through a sentence being typed. Both times, unrelated heavy diagnostics were running in another process (system_profiler SPBluetoothDataType, ioreg -c IOHIDDevice -r, several sqlite3 reads of TCC.db). The first half of the sentence was doubled and the second half was clean.

This bears on cause. A webview keydown listener that was never torn down should be indifferent to unrelated system load. A CGEventTap is not: macOS disables a tap that misses its response deadline (kCGEventTapDisabledByTimeout), and a saturated machine is what makes it miss. If that is the mechanism, this should be drivable on demand — load the machine, let it settle, and watch the transitions in both directions.

Worth noting this is not the same as your load finding. You reproduced the doubling at both high and low load, which rules load out as a trigger. What I am reporting is load appearing to act as a terminator, which is compatible with your result.

2. Paste is not a stable discriminator between this issue and #92622 — it degrades within one process lifetime.

#92622 reports paste unaffected; you report paste duplicating. Both were true here in the same session, in that order, with no restart in between. Paste stayed clean for roughly the first hour of an episode and then began duplicating the whole pasted block, exactly as you describe.

That suggests #92622 and this issue are one bug at two severities rather than two bugs, and that paste duplication is a later stage rather than a separate fault. #92622 is currently labelled invalid and has never been triaged; if the two are the same, that report contains scoping work worth keeping.

3. The renderer signature you identified was absent throughout my episode.

~/Library/Logs/Claude/unknown-window.log here contains 104 occurrences of

[error] Electron sandboxed_renderer.bundle.js script failed to run
[error] TypeError: Cannot destructure property 'preloadScripts' of 'binding.startupData' as it is null.

but the most recent is dated 2026-09-03, seven days before this episode. Doubling recurred at least four times on 2026-09-10 and produced no new occurrences.

I am not disputing your correlation — the clustering you documented is real. It looks like that failure is sufficient but not necessary, so a fix aimed only at preload initialisation would likely leave this reproducible.

---

Also ruled out here, recorded so it is not re-investigated

• Session count and app load — six live sessions; doubling present and absent at comparable loads.
• Accessibility permission. Revoking it for com.anthropic.claudefordesktop and com.anthropic.claude-code looked like it helped, but the toggle only persists if the app is quit first, and quitting alone already clears the symptom. Confounded, so I am reporting it as inconclusive rather than as a workaround. Also worth flagging for anyone tempted: revoking it disables computer-use entirely.

What I could not determine

I enumerated every event tap on the machine with CGGetEventTapList during a clean window with Accessibility granted. Claude held zero keyboard taps; the four enabled keyboard taps present belonged to Siri, SiriNCService, ViewBridgeAuxiliary, and an unrelated computer-use service.

That is not evidence against the tap theory, because CGGetEventTapList does not report NSEvent local or global monitors. I am now sampling tap counts every five seconds so that a doubling window is captured with its tap state; two enabled keyboard taps owned by Claude during such a window would settle it. A zero would only mean the cause sits where that API cannot look.

Happy to run anything specific against this machine while it is still reproducing.

Still present on a much newer build (2.9939.2), recurring and getting more frequent. Four data points that bear on the cause theories in this thread.

Environment

• Claude desktop 2.9939.2, Electron 44.4.3, Chrome 152.0.7977.130; bundled claude-code 2.1.281
• Running with a custom third-party provider setup (user data under Claude-3p), in case the 3P shell differs
• macOS Darwin 25.6.0 (build 25G229), Apple M3 Pro, 36 GB, US layout, internal keyboard
• About 15 Code sessions open in the app, single pane in the main window
• Frequency: seen multiple times, before the latest upgrade too, and noticeably more often since it

Symptom: identical to the report. Every key event doubles, space included, so NSAutomaticPeriodSubstitutionEnabled turns the doubled spaces into . (there is arrives as tthheerree. iiss.). Other apps type cleanly at the same moment.

1. The hardware/HID layer is clean while the app doubles. This machine runs Karabiner-Elements 16.3.0, so I checked it rather than assume. With doubling active in Claude, Karabiner-EventViewer showed exactly one down and one up per key coming out of the Karabiner virtual keyboard, and EventViewer's own text field received a single character. No Karabiner rule is scoped to Claude's bundle id. So the duplication is introduced inside the app, after the events leave the HID stack. (This also means a remapper is present here but demonstrably not the cause; earlier reporters had none.)

2. Cmd+R does not clear it; only a full Cmd+Q relaunch does. Reloading the renderer left the doubling in place. Quitting the app completely and relaunching fixed it (until the next episode). If a renderer reload rebuilds the webview's JS listeners, a leaked webview keydown listener should not survive it, which points toward state held in the main process or in native input handling (compatible with the event-tap theory in the comment above).

3. No preload failure signature at all. Zero occurrences of Cannot destructure property 'preloadScripts' of 'binding.startupData' in any log under ~/Library/Logs/Claude-3p/ or ~/Library/Logs/Claude/, and unknown-window.log is empty. Agrees with the earlier comment that the preload failure is not necessary for this bug.

4. Timeline and the only log anomaly. The bad run started at 00:23:46 local time and doubling was present by 00:41 (under 20 minutes after a cold launch); the app was quit at 02:08:15. The main log has no crash, hang, render-process-gone, or input-related entry in that window. The one recurring anomaly in the renderer log is, on every launch and on re-mounts within a single run:

[warn] MaxListenersExceededWarning: Possible EventEmitter memory leak detected. 11 ...claude.settings_$_AppPreferences_$_preferencesChanged listeners
[warn] MaxListenersExceededWarning: Possible EventEmitter memory leak detected. 11 ...claude.web_$_LocalSessions_$_onEvent listeners added
[warn] MaxListenersExceededWarning: Possible EventEmitter memory leak detected. 11 ...claude.settings_$_Custom3pSetup_$_bootstrapState_$store$_update

In an earlier run the same set appeared three times (00:12:24, 00:16:11, 00:16:28) with no app restart, so subscriptions are being re-registered without teardown. Not proven to be the input path, but it is the same class of fault that would double a key handler.

Paste behaviour was not tested during this episode. Full diagnostic logs (the app's own log export) are available privately on request; not attached here because they contain local paths and session activity.

Impact: the input box becomes unusable until a full quit, and a full quit interrupts every in-flight session in the app, so there is no workaround that keeps running work alive.