Environment
- OS: Windows 11 + WSL2 (opencode inside WSL, Warp on Windows)
- Warp: latest stable (Windows)
- OpenCode: 1.14.33
- Plugin: @warp-dot-dev/opencode-warp 0.1.5
Description
The plugin does not work at all from WSL. Two independent bugs prevent any OSC 777 notifications from being sent:
Bug 1: WARP_CLI_AGENT_PROTOCOL_VERSION is not set inside WSL
Warp for Windows does not propagate WARP_CLI_AGENT_PROTOCOL_VERSION into WSL Linux environments. This env var is checked in two places:
-
dist/index.js — WarpPlugin() function (line ~42): If the env var is missing, the plugin returns return {}; — zero event handlers are registered. The plugin loads but does nothing.
-
dist/notify.js — warpNotify() function (line ~8): If the env var is missing, the function silently returns without writing the OSC 777 escape sequence.
// dist/index.js — original code
if (!process.env.WARP_CLI_AGENT_PROTOCOL_VERSION) {
client.app.log({ ... warn ... }).catch(...);
return {}; // ← Bails out. No handlers registered.
}
// dist/notify.js — original code
function warpNotify(title, body) {
if (!process.env.WARP_CLI_AGENT_PROTOCOL_VERSION)
return; // ← Silently does nothing
// ...
}
Bug 2: session.created fires before the plugin registers its handlers
Confirmed via OpenCode logs (~/.local/share/opencode/log/): the plugin's warning log appears at +794ms from loading, while the internal server starts handling requests much earlier. The session.created event (which triggers the session_start notification that dismisses Warp's "setup plugin" chip) fires before the plugin's async WarpPlugin() function returns with the registered handlers.
Even if Bug 1 is fixed, the session_start notification is never sent because the session.created event is missed.
Bug 3 (bonus): Plugin lives in opencode's cache, not in user-visible node_modules
OpenCode resolves and caches plugins to ~/.cache/opencode/packages/@warp-dot-dev/opencode-warp@latest/node_modules/. Plugins installed to ~/.config/opencode/node_modules/ or ~/.opencode/node_modules/ are not the ones loaded at runtime. Users modifying the wrong copy see no effect.
Fix applied and verified working
Fix 1: Remove WARP_CLI_AGENT_PROTOCOL_VERSION guard from dist/index.js
Instead of return {} when the env var is missing, continue registering all event handlers. Log a warning instead of bailing out:
// After fix
if (!process.env.WARP_CLI_AGENT_PROTOCOL_VERSION) {
client.app.log({ ... warn ... }).catch(...);
// ← No return {}. Falls through to register handlers.
} else {
client.app.log({ ... info ... }).catch(...);
}
// ← Returns event handlers regardless of env var
return { event: ..., "chat.message": ..., ... };
Fix 2: Remove WARP_CLI_AGENT_PROTOCOL_VERSION guard from dist/notify.js
Always try to write the OSC 777 sequence. Use /dev/tty first, fall back to process.stderr.write():
// After fix
function warpNotify(title, body) {
const sequence = `\x1b]777;notify;${title};${body}\x07`;
try {
writeFileSync("/dev/tty", sequence);
return;
} catch {}
try {
process.stderr.write(sequence);
} catch {}
}
Fix 3: Send session_start after init to fix timing issue
Added a deferred (non-blocking) session list query during plugin initialization. Uses setTimeout because the HTTP server may not be ready when the plugin loads (client.session.list() hangs without a timeout since req.timeout = false):
// Added to WarpPlugin(), after the init log
const cwd = directory || "";
setTimeout(async () => {
try {
const sessions = await client.session.list();
if (sessions?.data?.length > 0) {
const sessionId = sessions.data[0].id;
const body = buildPayload("session_start", sessionId, cwd, {
plugin_version: PLUGIN_VERSION,
});
warpNotify(NOTIFICATION_TITLE, body);
}
} catch {}
}, 2000);
This also keeps the original session.created event handler for new sessions.
Verification
After applying the fixes to the cached copy at:
~/.cache/opencode/packages/@warp-dot-dev/opencode-warp@latest/node_modules/@warp-dot-dev/opencode-warp/dist/
- Warp notification appear on startup (session_start)
- Notifications appear on task completion (session.idle)
- OSC 777 sequences confirmed to reach Warp from WSL via manual
echo test
Related issues
Environment
Description
The plugin does not work at all from WSL. Two independent bugs prevent any OSC 777 notifications from being sent:
Bug 1:
WARP_CLI_AGENT_PROTOCOL_VERSIONis not set inside WSLWarp for Windows does not propagate
WARP_CLI_AGENT_PROTOCOL_VERSIONinto WSL Linux environments. This env var is checked in two places:dist/index.js—WarpPlugin()function (line ~42): If the env var is missing, the plugin returnsreturn {};— zero event handlers are registered. The plugin loads but does nothing.dist/notify.js—warpNotify()function (line ~8): If the env var is missing, the function silently returns without writing the OSC 777 escape sequence.Bug 2:
session.createdfires before the plugin registers its handlersConfirmed via OpenCode logs (
~/.local/share/opencode/log/): the plugin's warning log appears at+794msfrom loading, while the internal server starts handling requests much earlier. Thesession.createdevent (which triggers thesession_startnotification that dismisses Warp's "setup plugin" chip) fires before the plugin's asyncWarpPlugin()function returns with the registered handlers.Even if Bug 1 is fixed, the
session_startnotification is never sent because thesession.createdevent is missed.Bug 3 (bonus): Plugin lives in opencode's cache, not in user-visible node_modules
OpenCode resolves and caches plugins to
~/.cache/opencode/packages/@warp-dot-dev/opencode-warp@latest/node_modules/. Plugins installed to~/.config/opencode/node_modules/or~/.opencode/node_modules/are not the ones loaded at runtime. Users modifying the wrong copy see no effect.Fix applied and verified working
Fix 1: Remove
WARP_CLI_AGENT_PROTOCOL_VERSIONguard fromdist/index.jsInstead of
return {}when the env var is missing, continue registering all event handlers. Log a warning instead of bailing out:Fix 2: Remove
WARP_CLI_AGENT_PROTOCOL_VERSIONguard fromdist/notify.jsAlways try to write the OSC 777 sequence. Use
/dev/ttyfirst, fall back toprocess.stderr.write():Fix 3: Send
session_startafter init to fix timing issueAdded a deferred (non-blocking) session list query during plugin initialization. Uses
setTimeoutbecause the HTTP server may not be ready when the plugin loads (client.session.list()hangs without a timeout sincereq.timeout = false):This also keeps the original
session.createdevent handler for new sessions.Verification
After applying the fixes to the cached copy at:
~/.cache/opencode/packages/@warp-dot-dev/opencode-warp@latest/node_modules/@warp-dot-dev/opencode-warp/dist/echotestRelated issues