Skip to content

v2.0.8-rc4

Pre-release
Pre-release

Choose a tag to compare

View all tags
@github-actions github-actions released this 04 Jul 01:18
· 66 commits to main since this release
v2.0.8-rc4
abf0fe9
This commit was signed with the committer’s verified signature.
Khip01 Akhmad Aakhif Athallah
GPG key ID: 0285D5EE1A28FC4D
Verified
Learn about vigilant mode.

Installation

Fresh install

npm install -g https://github.com/Khip01/opencode-rich-presence/releases/download/v2.0.8-rc4/opencode-rich-presence-v2.0.8-rc4.tgz
opencode-rpc install

The installer creates a symlink at ~/.config/opencode/plugins/opencode-rich-presence.js so OpenCode loads the plugin as a local file (the package is distributed only via GitHub Releases, not the npm registry). It also adds @xhayper/discord-rpc to your local package.json and runs npm install so the worker can resolve its dependency.

Do not add opencode-rich-presence to the plugin array in opencode.jsonc. OpenCode reads that array as a list of npm packages to fetch on startup. The package is not on the npm registry, so adding it there causes a 404 notification on every OpenCode launch. The symlink alone is sufficient.

If you are upgrading from v2.0.5 and have a stale entry in opencode.jsonc, the installer detects it on the next opencode-rpc install and offers to remove it (default Yes).

Update from v2.0.x

opencode-rpc update

Or reinstall manually:

npm install -g https://github.com/Khip01/opencode-rich-presence/releases/download/v2.0.8-rc4/opencode-rich-presence-v2.0.8-rc4.tgz

Migrating from v1.0.0

v1.0.0 used bash scripts (install, uninstall, restart-discord.sh) and was Linux-only.

  1. Back up your old ~/.config/opencode/discord-config.json if you have one.
  2. Run the fresh install command above.
  3. Run opencode-rpc install to set up the new config file.
  4. Restore your settings into the new config (App ID, presence templates).
  5. Manually remove old v1.0.0 leftovers from ~/.config/opencode/: 
    rm -rf ~/.config/opencode/plugins/opencode-dc-too-rich-presence.js
rm -f ~/.config/opencode/discord-worker.mjs
rm -f ~/.config/opencode/restart-discord.sh
rm -f ~/.config/opencode/package.json ~/.config/opencode/package-lock.json
rm -f ~/.config/opencode/CUSTOMIZATION.md ~/.config/opencode/README.md ~/.config/opencode/SETUP.md
  6. Restart OpenCode.

The plugin name changed from opencode-dc-too-rich-presence to opencode-rich-presence.

What's in v2.0.8

Fix: shutdownWorker no longer signal-kills an already-exited child

  • The previous implementation sent SIGTERM 200ms after the shutdown command, regardless of whether the worker had exited
  • Linux reuses PIDs, so the new leader's worker could spawn with the same PID and then receive a stray SIGTERM from the old leader's cached ChildProcess reference
  • This caused Worker exited: code=null sig=SIGTERM immediately after a handoff, killing the new leader's worker
  • Fixed by polling child.exitCode and child.signalCode and only force-killing if the worker is genuinely still alive

Fix: leader cooldown prevents handoff oscillation

  • v2.0.7 yielded leadership as soon as a standby's lastActivity was fresher than the leader's
  • Every instance receives every SDK event, so multi-instance setups ping-ponged leadership and the Discord presence flickered every few seconds
  • v2.0.8+ ignores handoff signals for LEADER_COOLDOWN_MS (8 seconds) after becoming leader, so the active window keeps Discord presence for at least that long

Fix: only user-initiated events request handoff

  • chat.message, session.created/updated, session.status busy, message.updated, and message.part.updated now opt out of handoff
  • Only chat.message, permission.asked, and permission.replied still request handoff
  • Agent-side events still markActive but do not request leadership

Fix: 2s IPC release delay before new leader connects

  • The new leader now waits 2 seconds before calling startConnect()
  • Gives the previous leader's worker time to fully release the Discord IPC socket

Fix: forced state refresh on leadership gain

  • The new leader calls checkAllSessionsActivity() after gaining leadership
  • Standby instances do not poll, so their in-memory session states can be stale
  • This fixes the "display stuck at Typing after handoff" symptom

What's in v2.0.7

Fix: multi-instance leader election is now activity-based

  • Previously, the first OpenCode instance to start held the leader lock indefinitely
  • Standby instances could not push to Discord, even when actively chatting
  • Result: a previously idle leader showed stale presence while another instance was generating messages

Fix: standby instances can now take over leadership

  • Standby writes a handoff signal at ~/.config/opencode/.opencode-rich-presence-handoff when it receives chat.message or other activity events
  • Leader's heartbeat reads the signal and releases the lock if the request is fresher than its own activity
  • Standby picks up the lock on its next 2s poll and starts pushing to Discord
  • Total handoff time: ~7 seconds from your first message in the active window

Fix: leadership-change callback drives Discord worker lifecycle

  • startConnect() on gain, shutdownWorker() on loss
  • shutdownWorker() is distinct from destroy() (which is permanent) so the instance can re-acquire leadership later

Chore: docs

  • docs/ARCHITECTURE.md rewrites the Multi-instance Coordinator section
  • docs/TROUBLESHOOTING.md adds a root cause entry for "idle leader shows stale presence"
  • CHANGELOG.md adds v2.0.7 entry
  • Project AGENTS.md adds Critical Implementation Details for the new coordinator flow and a known-bug entry for the old first-wins design

See CHANGELOG.md for full details.

Assets 3
Loading