warp-notify.sh emits 'device not configured' diagnostic when /dev/tty is unavailable in hook context

[drewdrewthis]

Symptom

When scripts/on-prompt-submit.sh (and other hooks invoking warp-notify.sh) run in a non-interactive context — e.g., a Claude Code hook chain without a controlling terminal — the redirect to /dev/tty in warp-notify.sh produces a shell-level diagnostic that the inline 2>/dev/null cannot suppress:

warp-notify.sh: line 21: /dev/tty: Device not configured

This surfaces in Claude Code as UserPromptSubmit hook error: Failed with non-blocking status code: No stderr output on every user prompt.

Repro

echo '{"hook_event_name":"UserPromptSubmit","session_id":"x","cwd":"/tmp","prompt":"t","agent_name":"a"}' \
  | CLAUDE_PLUGIN_ROOT=/path/to/warp/2.0.0 \
    bash /path/to/warp/2.0.0/scripts/on-prompt-submit.sh

Observed: shell diagnostic on stderr, exit 0, surfaced as hook error in Claude Code.

Environment

• macOS (Darwin)
• Claude Code, plugin version 2.0.0

(A working local patch and proposed fix follow as a comment so the issue body stays a stub.)

[drewdrewthis]

Proposed fix (working locally)

2>/dev/null on the redirect suppresses stderr of the printf, but the shell emits its own diagnostic about the failed redirection BEFORE the redirection opens. That diagnostic goes to the shell's outer stderr, not the command's stderr. [ -w /dev/tty ] doesn't help — the device has 666 permissions; it reports writable even when the process has no controlling terminal.

Wrap the redirect in a group-level redirect, which suppresses the shell diagnostic:

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

The { : > /dev/tty; } 2>/dev/null block attempts to open /dev/tty with stderr suppressed at the group level (which IS suppressible, because the group's stderr is redirected before inner commands run). If the open fails silently, skip the notification entirely.

Confirmed working: clean exit, no stderr, in the same repro as above.