warp-notify.sh prints "/dev/tty: Device not configured" when invoked without a controlling TTY

[istefox]

Summary

scripts/warp-notify.sh (v2.0.0) writes OSC 777 sequences directly to /dev/tty. When the hook runs in a subprocess that has no controlling terminal — which is common for hooks dispatched by Claude Code (e.g. on Notification, PostToolUse, Stop) — the redirect itself fails before printf's 2>/dev/null can take effect, surfacing as a spurious bash: line 21: /dev/tty: Device not configured in the host UI. Exit code stays 0, so the user only sees the warning.

Reproduction

On macOS, with the plugin enabled and a Warp build that supports OSC 777 (should_use_structured returns true):

nohup bash ~/.claude/plugins/cache/claude-code-warp/warp/2.0.0/scripts/warp-notify.sh "test" "body" </dev/null

→ stderr contains bash: line 21: /dev/tty: Device not configured even though the script otherwise exits 0.

Root cause

> /dev/tty 2>/dev/null only suppresses printf's stderr. The shell-level redirection failure (opening /dev/tty for writing when there is no controlling TTY) is reported on the shell's stderr, before any of the redirections on the printf command apply.

Proposed fix

Guard the write with a writability test. Drop-in replacement for line 21:

if [ -w /dev/tty ]; then
    printf '\033]777;notify;%s;%s\007' "$TITLE" "$BODY" > /dev/tty 2>/dev/null || true
fi

This silences the warning for invocations without a TTY (which legitimately can't deliver the notification anyway) while preserving the existing behaviour when a TTY is present.

Environment

• macOS 26 (Tahoe), zsh
• Warp v0.2026.04.29.08.57.stable_01, WARP_CLI_AGENT_PROTOCOL_VERSION=1
• Plugin claude-code-warp v2.0.0
• Claude Code (CLI)

Happy to open a PR with the change if useful — let me know.

[istefox]

Correction to my initial proposal. I tested [ -w /dev/tty ] empirically and it does not silence the warning: /dev/tty keeps writable permission bits even on a process without a controlling terminal, so the test passes but the subsequent > redirection still fails.

The guard that actually works is to probe /dev/tty by opening a file descriptor in a subshell and skipping silently if the open fails:

if (exec 3>/dev/tty) 2>/dev/null; then
    printf '\033]777;notify;%s;%s\007' "$TITLE" "$BODY" > /dev/tty 2>/dev/null || true
fi

Verified on macOS 26 / bash 3.2: nohup bash warp-notify.sh "t" "b" </dev/null now exits 0 with no stderr output, while a normal interactive invocation still delivers the OSC sequence.

Happy to open a PR with this version.