Plugin broken in WSL + fix
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 35/100
- Issue type
- Bug
- Clarity
- Clearly specified
- Activity status
- Quiet
- Tech stack
- typescript
- Domain
- tooling
Research direction
Start with dist/index.js and dist/notify.js, reading the WarpPlugin and warpNotify entry points and the related issues #11, #15, and #17. Verify plugin initialization and notification behavior from WSL, including startup and task-completion events. Done means handlers register and OSC 777 notifications reach Warp without relying on a user-editable cache copy.
Written by the indexing model from the issue text.
Description
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 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.
// 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
echotest
Related issues
- #11 — Plugin setup notification never disappears (same symptoms, Windows 11)
- #15 — fix(notify): cross-platform TTY write
- #17 — Plugin not generating OSC 777 notifications
- Dominant language
- TypeScript
- Stars
- 30
- Forks
- 16
- PR merge metrics
- No merged PRs in 30d
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from warpdotdev/opencode-warp
-
Difficulty 2/5 1-3 hours Newbie friendliness 74/100
warpdotdev/opencode-warp#27 · 1 comment · 3 reactions ·
All issues in warpdotdev/opencode-warp
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
mksglu/context-mode#1200 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
jaegertracing/jaeger-ui#4506 ·
-
area:desktop area:ui bug platform:macos
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
anthropics/claude-code#96687 ·
-
good first issue
Difficulty 1/5 Under an hour Newbie friendliness 95/100
AOSSIE-Org/DebateAI#582 · 2 comments ·