Environment
- OS: Windows 11
- Warp version: v0.2026.05.06.15.42.stable_05
- Claude Code version: 2.1.77
- Shell: Git Bash (MSYS2)
- Plugin version: warp@claude-code-warp 2.0.0
- TERM_PROGRAM: WarpTerminal
- WARP_CLI_AGENT_PROTOCOL_VERSION: 1
Problem
Warp notifications from the Claude Code plugin never appear on Windows. All hooks fire correctly (verified via debug logging to /tmp/warp-debug.log), should_use_structured returns true, and build-payload.sh constructs valid JSON — but the notification never reaches Warp.
Root Cause
warp-notify.sh sends the OSC 777 escape sequence via:
printf '\033]777;notify;%s;%s\007' "$TITLE" "$BODY" > /dev/tty
On Windows (Git Bash), this fails because:
-
/dev/tty fails to open — Git Bash inside Claude Code's hook runner cannot access /dev/tty. It exists as a path but writing to it gives: /dev/tty: No such device or address
-
stderr fallback is captured — The fallback >&2 writes to stderr, but Claude Code's hook execution framework captures both stdout and stderr from hook subprocesses (stdout is used for structured JSON responses like systemMessage). The OSC sequence goes into Claude Code's internal buffer, never reaching Warp's terminal emulator.
-
No alternative fd exists — Unlike macOS/Linux where /dev/tty reliably connects to the controlling terminal, Windows has no equivalent side-channel that bypasses Claude Code's stdio capture.
Verified Working
should_use_structured → returns 0 (true) ✅jq installed (1.8.1) ✅build-payload.sh → produces valid JSON ✅- Hook scripts fire on Stop, Notification, SessionStart events ✅
- Plugin enabled in settings.json ✅
Debug Log (hooks are firing)
[WARP DEBUG] on-stop.sh fired at Sat May 16 21:18:31 IST 2026
[WARP DEBUG] on-stop.sh fired at Sat May 16 21:19:09 IST 2026
[WARP DEBUG] on-notification.sh fired at Sat May 16 21:20:12 IST 2026
[WARP DEBUG] on-stop.sh fired at Sat May 16 21:24:37 IST 2026
[WARP DEBUG] on-notification.sh fired at Sat May 16 21:25:39 IST 2026
Suggestion
The plugin needs a Windows-compatible delivery mechanism for OSC sequences. Possible approaches:
- Use Warp's IPC/socket if one exists (env var like
WARP_SOCKET?)
- Request Claude Code to pass through OSC sequences from hook output instead of capturing them
- Use a Windows-specific API (ConPTY handle) to write directly to the terminal
This is a Windows-only issue — macOS/Linux work fine since /dev/tty connects directly to the controlling terminal.
Environment
Problem
Warp notifications from the Claude Code plugin never appear on Windows. All hooks fire correctly (verified via debug logging to
/tmp/warp-debug.log),should_use_structuredreturns true, andbuild-payload.shconstructs valid JSON — but the notification never reaches Warp.Root Cause
warp-notify.shsends the OSC 777 escape sequence via:On Windows (Git Bash), this fails because:
/dev/ttyfails to open — Git Bash inside Claude Code's hook runner cannot access/dev/tty. It exists as a path but writing to it gives:/dev/tty: No such device or addressstderr fallback is captured — The fallback
>&2writes to stderr, but Claude Code's hook execution framework captures both stdout and stderr from hook subprocesses (stdout is used for structured JSON responses likesystemMessage). The OSC sequence goes into Claude Code's internal buffer, never reaching Warp's terminal emulator.No alternative fd exists — Unlike macOS/Linux where
/dev/ttyreliably connects to the controlling terminal, Windows has no equivalent side-channel that bypasses Claude Code's stdio capture.Verified Working
should_use_structured→ returns 0 (true) ✅jqinstalled (1.8.1) ✅build-payload.sh→ produces valid JSON ✅Debug Log (hooks are firing)
Suggestion
The plugin needs a Windows-compatible delivery mechanism for OSC sequences. Possible approaches:
WARP_SOCKET?)This is a Windows-only issue — macOS/Linux work fine since
/dev/ttyconnects directly to the controlling terminal.