Notifications silently fail under Claude Code: hook subprocess has no controlling TTY, OSC 777 write to /dev/tty is dropped

[Zmetser]

Summary

When the plugin runs under Claude Code (CLAUDECODE=1), scripts/warp-notify.sh writes the OSC 777 escape sequence to /dev/tty, but Claude Code spawns hook subprocesses without a controlling TTY, so the write fails silently and no notification ever reaches Warp.

• Plugin version: 2.0.0
• Warp version: v0.2026.05.13.09.15.stable_01 (also reproduced on v0.2026.05.06.15.42.stable_04)
• Claude Code: 2.1.142 on macOS (Darwin 25.3.0)

Repro

1. Install the plugin in Claude Code, restart / /reload-plugins.
2. Confirm WARP_CLI_AGENT_PROTOCOL_VERSION=1 and WARP_CLIENT_VERSION are set (they are).
3. Confirm Warp's "Receive desktop notifications" + agent toggles are on.
4. Run anything in Claude Code that triggers Stop, PermissionRequest, or idle Notification hooks.
5. Expected: native Warp/macOS notification. Actual: nothing fires.

Root cause

Adding debug logging to warp-notify.sh shows every hook firing with:

/dev/tty: Device not configured
  /dev/tty exists but NOT writable
  tty: not a tty
  printf to /dev/tty FAILED

The hook subprocess Claude Code spawns has no controlling terminal, so > /dev/tty errors. The 2>/dev/null || true swallows the error, so the failure is invisible.

Workaround / suggested fix

Walk up the process tree to find the nearest ancestor with a real tty (the parent claude process keeps its tty, e.g. ttys003), and write the OSC sequence to that device directly. Patch that works locally:

find_parent_tty() {
    local pid=$PPID
    local tty
    while [ -n "$pid" ] && [ "$pid" != "1" ] && [ "$pid" != "0" ]; do
        tty=$(ps -o tty= -p "$pid" 2>/dev/null | tr -d ' ')
        if [ -n "$tty" ] && [ "$tty" != "??" ] && [ "$tty" != "-" ]; then
            echo "/dev/$tty"
            return 0
        fi
        pid=$(ps -o ppid= -p "$pid" 2>/dev/null | tr -d ' ')
    done
    return 1
}

TARGET_TTY=$(find_parent_tty)
if [ -n "$TARGET_TTY" ] && [ -w "$TARGET_TTY" ]; then
    printf '\033]777;notify;%s;%s\007' "$TITLE" "$BODY" > "$TARGET_TTY" 2>/dev/null || true
else
    printf '\033]777;notify;%s;%s\007' "$TITLE" "$BODY" > /dev/tty 2>/dev/null || true
fi

With this in place, Stop / PermissionRequest / idle notifications all fire correctly.

Minor

The resulting notifications show a generic folder icon rather than the Warp icon — not sure if that's a separate macOS notification-attribution issue or related to the OSC 777 path.

[Zmetser]

Looks like #44 is already proposing this fix — same approach (walk the parent process tree for a usable tty), more thorough than the snippet here: factored into a reusable helper, patches both structured and legacy paths, iterates all candidate ancestors rather than stopping at the first, and adds unit tests. Happy to close this in favor of #44.

One data point worth flagging for the PR description: #44 frames the trigger as Claude Code's opt-in sandbox-exec wrapper ("sandbox": {"enabled": true} in .claude/settings.json). I reproduced this without any sandbox config in either project or user settings — plain Claude Code 2.1.142 on macOS, no sandbox opt-in. So the tty-detached subprocess behavior appears to be the default for hooks now, not just sandbox mode. May be worth verifying on the PR side before merge so the framing matches what users will actually hit.

[acabreragnz]

Confirming reproduction on Linux (Ubuntu 24.04) without any sandbox configuration.

• Claude Code: 2.1.145
• Warp: v0.2026.04.29.08.57.stable_01
• Plugin: warp@claude-code-warp v2.0.0
• No sandbox key in .claude/settings.json (neither project nor user settings)

The tty-detached hook behavior is the default on this setup — not tied to the opt-in sandbox-exec wrapper mentioned in PR #44's description. Hooks run with:

fd/0 → /dev/null
fd/1 → /tmp/claude-1000/.../tasks/<id>.output
fd/2 → /tmp/claude-1000/.../tasks/<id>.output

Verified via /proc/$$/fd from inside a hook subprocess. tty returns not a tty. Every printf > /dev/tty fails with ENXIO, silently swallowed by || true.

Also caught a secondary bug: the [ -w /dev/tty ] check inside _find_tty() tests file permission bits, not whether the device is openable. /dev/tty has crw--w---- permissions and the user is in the tty group, so the check returns true even with no controlling terminal — causing _find_tty() to return /dev/tty and the subsequent write to fail anyway. Fix is to use ( : > /dev/tty ) 2>/dev/null instead.

PR #44 fix confirmed working on Linux: walking the parent process tree (/proc/$PPID/fd/1) finds the Claude Code process's /dev/pts/N and the OSC 777 write succeeds. Notifications appear correctly after patching warp-notify.sh locally.

Worth updating PR #44's description to note that the TTY-detached behavior is default (not just sandbox mode) — it affects a wider set of users than the current framing suggests.