fix: stop notifying on every shell prompt redraw (ConEmu OSC 9 subcommands) - #127
Conversation
OSC 9 is overloaded: iTerm2 uses it for notifications (OSC 9;<text>), but ConEmu/Windows Terminal use numeric subcommands — 9;<cwd> (cwd report, emitted by our cmd integration and the standard WT PowerShell prompt snippet on every prompt redraw) and 4;<state>;<n> (progress). The handler treated every payload as a notification, so each command typed at a shell prompt fired a bogus one. Swallow numeric-subcommand payloads; bare-text notifications still fire. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
#127 correctly identified that the OSC 9 handler treated ConEmu numeric subcommands as iTerm2 notification text, so every cmd prompt redraw raised a bogus notification. It guarded them with `return true`. xterm runs OSC handlers newest-first and stops at the first returning true. ProgressAddon registers on OSC 9 too, but is loaded before this handler, so the notification handler always wins the sequence. Returning true therefore still consumed 9;4 — the progress bar in the tab strip, sidebar and Windows taskbar has been fed nothing since it shipped in 0.23.0. Return false instead: the guard declines the sequence and xterm continues down the chain to ProgressAddon. Notification spam stays fixed, and progress starts working for the first time. The predicate moves to hooks/osc9.ts so it is testable, with a regression test driving real xterm + real ProgressAddon in wmux's registration order. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01HorCxLMH2pVuR16QyZCroL
|
Merged, thank you — and the diagnosis turned out to uncover a second, older bug. Your root-cause analysis was exactly right: While verifying the fix I checked what else registers on OSC 9, and found this: xterm dispatches OSC handlers newest-registered-first, stopping at the first one returning I confirmed it with real xterm + real
The OSC 9;4 progress bar — tab strip, sidebar, Windows taskbar — has been fed nothing since it shipped in 0.23.0, because this handler has been eating every OSC 9 the whole time. So I merged your PR as-is and pushed a follow-up (2be9d41) flipping Shipping in v0.39.0. |
Problem
wmux fires a notification every time a command is run at a shell prompt — extremely noisy alongside the (desired) agent notifications.
Root cause
The OSC 9 handler in
useTerminal.tstreats every OSC 9 payload as an iTerm2-style notification (OSC 9;<text>). But OSC 9 is overloaded: ConEmu/Windows Terminal use numeric subcommands —OSC 9;9;<cwd>(cwd report) andOSC 9;4;<state>;<n>(progress). wmux's ownwmux-cmd-integration.cmdembeds9;9;$Pin the cmd prompt, and the standard Windows Terminal PowerShell profile snippet does the same — so every prompt redraw after every command raised a bogus notification with text like9;C:\path.Fix
One guard in the OSC 9 handler: payloads starting with a numeric subcommand (
/^\d+;/) are swallowed instead of raised. Bare-text notifications,wmux notify, and the Claude Code Stop/Notification hook path are unaffected.Testing
Verified in a dev instance:
ESC ]9;9;C:\fake BELandESC ]9;4;1;50 BEL→ silent (previously each fired a notification)ESC ]9;hello BEL→ still notifieswmux notifyand agent Stop-hook notifications still work🤖 Generated with Claude Code