Bug Description
warpNotify() in notify.ts writes OSC 777 escape sequences via writeFileSync("/dev/tty", ...). This fails silently on Windows because /dev/tty is a Unix-only device. The catch block swallows the error, so no notifications ever reach Warp on Windows (and possibly other platforms where the plugin subprocess lacks a controlling terminal).
This causes:
- Setup chip never disappears (Warp never receives
session_start)
- No notifications for task completion, permission requests, or tool use
- Plugin appears non-functional despite being correctly installed
Root Cause
OpenCode plugins run as JavaScript modules inside a Bun/Node.js subprocess managed by OpenCode's plugin loader. Unlike Claude Code's shell-based hooks (which execute printf ... > /dev/tty in bash with direct terminal access), the OpenCode plugin's writeFileSync("/dev/tty") fails because:
- Windows:
/dev/tty doesn't exist in the Windows filesystem — Node.js uses native Win32 file APIs
- Plugin subprocess: Even on Unix, the plugin process may not have
/dev/tty accessible if OpenCode spawns it with redirected stdio
Why PR #12's process.stdout.write() fallback doesn't work
PR #12 falls back to process.stdout.write(sequence) on failure. Users confirmed this still doesn't work because process.stdout in the plugin subprocess is piped to OpenCode's plugin loader for RPC communication — it doesn't reach the terminal.
Proposed Fix
Replace the single /dev/tty write with a platform-aware cascade:
- Unix: Try
writeFileSync("/dev/tty") (existing behavior, works when controlling terminal is available)
- Windows: Try
writeFileSync("CONOUT$") then writeFileSync("CON") — Windows console output devices that bypass stdio redirection
- Fallback: Try
process.stderr.write() (stderr is less commonly redirected than stdout)
Additionally, port the WARP_CLIENT_VERSION validation from claude-code-warp's should-use-structured.sh to avoid sending notifications to known-broken Warp builds that set WARP_CLI_AGENT_PROTOCOL_VERSION but can't render structured notifications.
Environment
- Affected OS: Windows 11 (confirmed), possibly macOS
- Warp: Latest stable
- OpenCode: 1.4.5+
- Plugin version: 0.1.5
Related
Bug Description
warpNotify()innotify.tswrites OSC 777 escape sequences viawriteFileSync("/dev/tty", ...). This fails silently on Windows because/dev/ttyis a Unix-only device. Thecatchblock swallows the error, so no notifications ever reach Warp on Windows (and possibly other platforms where the plugin subprocess lacks a controlling terminal).This causes:
session_start)Root Cause
OpenCode plugins run as JavaScript modules inside a Bun/Node.js subprocess managed by OpenCode's plugin loader. Unlike Claude Code's shell-based hooks (which execute
printf ... > /dev/ttyin bash with direct terminal access), the OpenCode plugin'swriteFileSync("/dev/tty")fails because:/dev/ttydoesn't exist in the Windows filesystem — Node.js uses native Win32 file APIs/dev/ttyaccessible if OpenCode spawns it with redirected stdioWhy PR #12's
process.stdout.write()fallback doesn't workPR #12 falls back to
process.stdout.write(sequence)on failure. Users confirmed this still doesn't work becauseprocess.stdoutin the plugin subprocess is piped to OpenCode's plugin loader for RPC communication — it doesn't reach the terminal.Proposed Fix
Replace the single
/dev/ttywrite with a platform-aware cascade:writeFileSync("/dev/tty")(existing behavior, works when controlling terminal is available)writeFileSync("CONOUT$")thenwriteFileSync("CON")— Windows console output devices that bypass stdio redirectionprocess.stderr.write()(stderr is less commonly redirected than stdout)Additionally, port the
WARP_CLIENT_VERSIONvalidation fromclaude-code-warp'sshould-use-structured.shto avoid sending notifications to known-broken Warp builds that setWARP_CLI_AGENT_PROTOCOL_VERSIONbut can't render structured notifications.Environment
Related
warpdotdev/claude-code-warpshould-use-structured.sh— version gating reference