Skip to content

fix: re-emit session_start after plugin init to fix missed handshake race - #25

Open
morozsm wants to merge 1 commit into
warpdotdev:mainfrom
morozsm:fix/session-start-init-race
Open

fix: re-emit session_start after plugin init to fix missed handshake race#25
morozsm wants to merge 1 commit into
warpdotdev:mainfrom
morozsm:fix/session-start-init-race

Conversation

@morozsm

Copy link
Copy Markdown

Problem

session.created is the only event that emits the session_start handshake, and it's what tells Warp the plugin is installed (dismisses the "Install Warp Plugin for OpenCode" instructions chip). However, plugin init is async: on the opencode versions we tested, session.created fires before the plugin's event handlers are registered, so the handshake is never sent and Warp keeps showing the setup instructions even though the plugin loads fine (Warp plugin initialized in the logs) and is listed in opencode.json.

Reproduced on macOS 26 (arm64), Warp v0.2026.08.05 stable, OpenCode 1.18.18, plugin 0.1.7 — same symptoms as #17, and the same root cause as the timing bug described in #18 (which also author-confirmed this fix approach on WSL). Likely explains #11 as well.

Fix

After successful init, re-emit session_start for the most recent top-level session via client.session.list():

  • Deferred by 2s — past event-bus attach; calling client.session.list synchronously during plugin init can hang.
  • A dedup flag (sessionStartSent) set by the session.created handler suppresses the re-emit when the event was caught normally, so there's never a double notification.
  • Sessions with a parentID are skipped when picking the handshake session, consistent with the subagent suppression in the rest of the plugin.

Test plan

  • Added tests/deferred-session-start.test.ts: deferred emit fires when session.created was never handled; dedup suppresses it when it was; subagent sessions are skipped when choosing the handshake session.
  • bun test — 28 pass / 0 fail; bun run typecheck clean; bun run build clean.
  • Manually verified end-to-end with the built plugin on Warp + OpenCode 1.18.18: handshake arrives after restart, the setup instructions chip disappears, and prompt_submit/stop/permission_request notifications work.

Fixes#17. Refs #18, #11.

Co-Authored-By: Oz oz-agent@warp.dev

…race)
Warp dismisses its "Install Warp Plugin" instructions only after
receiving the session_start handshake, which is emitted exclusively on
session.created. Because plugin init is async, session.created can fire
before the plugin's event handlers are registered, so the handshake is
never sent and Warp keeps showing the setup instructions even though the
plugin is loaded and working (warpdotdev#17, warpdotdev#18).
After init, re-emit session_start for the most recent top-level session
via client.session.list(), deferred by 2s (past event-bus attach;
calling client.session.list synchronously during init can hang). A dedup
flag skips the re-emit when the session.created handler already sent the
handshake, so no double notifications occur.
Fixeswarpdotdev#17
Refs warpdotdev#18, warpdotdev#11
Co-Authored-By: Oz <oz-agent@warp.dev>
@morozsm

Copy link
Copy Markdown
Author

Thanks for checking this. Confirming this is still reproducible on latest stable (Warp 0.2026.08.05 + OpenCode 1.18.18), and PR #25 fixes it locally end-to-end (setup chip clears; notifications work). Happy to adjust anything needed for merge.

Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Title: Plugin @warp-dot-dev/opencode-warp not generating OSC 777 notifications

1 participant

@morozsm