Windows Notification Still Not Working

[DICEKI]

Environment:

• Windows 10 Pro
• Warp: v0.2026.04.22.08.46.stable_03
• Claude Code warp plugin: 2.0.0

Issue:
Desktop notifications completely fail on Windows.

Diagnosis:
The warp-notify.sh script attempts to write OSC escape sequences to /dev/tty, which doesn't exist on
Windows:

printf '\033]777;notify;%s;%s\007' "$TITLE" "$BODY" > /dev/tty 2>/dev/null || true

The script silently fails because of || true - no fallback to stdout.

Root Cause:
PR #19 explicitly states that Windows is not supported and requires different TTY detection logic. There is
currently no alternative notification path for Windows users.

Impact:

• Stop hook runs but no notification appears
• should_use_structured() passes (version check OK)
• TTY detection works but /dev/tty doesn't exist on Windows
• Notification silently fails with no user feedback

Request:
Windows support for desktop notifications, or a fallback mechanism when /dev/tty is unavailable.

[MillhioreBT]

It doesn't work for me either; in fact, with Claude Code the Hook blocks the prompt because it doesn't expand the environment variables correctly when the Windows username contains spaces.

[JardarIversen]

Confirming on Windows 11 (DICE's repro is on Windows 10 — same root cause).

• Windows 11 Pro 26200
• Warp v0.2026.04.22.08.46.stable_03
• Claude Code plugin warp@2.0.0
• Git Bash 5.2.37 (MSYS) is the shell Claude Code's hook subprocess uses

Reproduced by running the hook script manually:

$ echo '{"stop_hook_active": false, "transcript_path": ""}' | bash on-stop.sh
build-payload.sh: line 49: jq: command not found
warp-notify.sh: line 21: /dev/tty: No such device or address

So on Windows there are actually two failure points stacked:

1. /dev/tty doesn't exist — same root cause @DICEKI identified. The OSC 777 escape sequence has no path back to the parent Warp console because Claude Code (Node) spawns the hook subprocess with piped stdio, and Windows has no /dev/tty for fallback.
2. jq is a hard dependency but not bundled or documented as a prerequisite. build-payload.sh and on-stop.sh both need it. Without jq, the payload silently becomes empty even before the /dev/tty write. Most Windows users don't have jq on PATH.

Possible Windows-friendly paths forward:

• Write the OSC sequence via PowerShell using AttachConsole(ATTACH_PARENT_PROCESS) + CONOUT$ so the bytes reach Warp's console regardless of the child's stdio.
• Or rewrite the JSON parsing in pure bash / a small embedded helper so jq isn't required.
• At minimum, surface the /dev/tty write failure (drop the 2>/dev/null || true swallow) so users get a clear error instead of silent no-op.

Happy to test patches on Windows 11 if useful.

[Nellyxxvi]

Confirming on a newer Warp build — bug still present.

Environment:

• Windows 11 Home (26200)
• Warp v0.2026.04.29.08.57.stable_02 (newer than the reports above)
• Claude Code plugin warp@2.0.0
• Git Bash / MSYS shell, jq 1.8.1 installed
• WARP_CLI_AGENT_PROTOCOL_VERSION=1, should_use_structured returns true

Useful isolation: the OSC 777 receiver itself works on Windows.

Running this manually from a Warp bash tab fires an in-app notification correctly:

printf '\033]777;notify;Test;Hello from manual OSC\007'

But running the plugin's script fails:

$ bash warp-notify.sh "Test" "Test"
warp-notify.sh: line 21: /dev/tty: No such device or address

So the bug is purely in the hook → /dev/tty path, not in Warp's receiver. The hook subprocess Claude Code spawns has no controlling terminal under MSYS, so the printf … > /dev/tty write fails and the 2>/dev/null || true swallows the error silently. With jq installed, the payload builds correctly — it just never reaches Warp.

Suggested fixes (matching @JardarIversen's list):

1. Detect Windows and write OSC bytes via PowerShell AttachConsole(ATTACH_PARENT_PROCESS) + CONOUT$.
2. Or fall back to writing the OSC sequence to stdout/stderr if /dev/tty is unavailable, in case Claude Code forwards hook output to the parent terminal.
3. At minimum, drop the silent error swallow so the failure is visible.

Happy to test patches on Win 11.

[AndreasKahlroth]

plz fix for Windows 🙏