Hacktoberfest 2026:メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

Plugin broken in WSL + fix

オープン
#18 コメント 0 件 リアクション 1 件 担当者 0 名 GitHub で見る

まだ誰も着手していません。

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
35/100
issue の種類
バグ
明瞭さ
明確に書かれている
活発さ
静か
技術スタック
typescript
領域
tooling

調査の方向性

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.

索引モデルが issue の本文から書いたものです。

説明

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/

  1. Warp notification appear on startup (session_start)
  2. Notifications appear on task completion (session.idle)
  3. OSC 777 sequences confirmed to reach Warp from WSL via manual echo test

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
主要言語
TypeScript
スター
30
フォーク
16
PR マージ指標
30日以内にマージされた PR はありません

コントリビューションガイド

このリポジトリのコントリビューションガイドは索引されていません

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

warpdotdev/opencode-warp のほかの issue

warpdotdev/opencode-warp の issue をすべて見る

似ている issue

TypeScript の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。