Releases: Khip01/opencode-rich-presence
Release list
v3.1.9
Installation
Stable (recommended for end users)
# Easiest path: one-liner curl installer. Works on
# Linux, macOS, and Windows (Git Bash / MSYS2 / Cygwin / WSL).
curl -fsSL https://raw.githubusercontent.com/Khip01/opencode-rich-presence/main/install.sh | bashPin to a specific version:
curl -fsSL https://raw.githubusercontent.com/Khip01/opencode-rich-presence/main/install.sh \
| ORP_VERSION=v3.1.9 bashManual install from the tarball (any platform, including Windows)
# Download from the asset below, then:
npm install -g ./opencode-rich-presence-v3.1.9.tgz
opencode-rpc installWhy not npm install -g Khip01/opencode-rich-presence#v3.1.9?
npm v11 has a bug installing global git deps: the install
appears to succeed (added 1 package) but the
opencode-rpc binary is missing. Always install from a
local tarball. See
TROUBLESHOOTING.md
for the full story.
Upgrade
Once installed, use opencode-rpc update to upgrade:
opencode-rpc update # latest stable release tag
opencode-rpc update --stable # force install latest stable
opencode-rpc update --dev <branch> # latest commit on <branch>
opencode-rpc update --ref v3.1.9 # install a specific tag, branch, or SHA
opencode-rpc update --repo <fork> # install from a forkWhat's in v3.1.9
See CHANGELOG.md for full details.
v3.1.8
Installation
Stable (recommended for end users)
# Easiest path: one-liner curl installer. Works on
# Linux, macOS, and Windows (Git Bash / MSYS2 / Cygwin / WSL).
curl -fsSL https://raw.githubusercontent.com/Khip01/opencode-rich-presence/main/install.sh | bashPin to a specific version:
curl -fsSL https://raw.githubusercontent.com/Khip01/opencode-rich-presence/main/install.sh \
| ORP_VERSION=v3.1.8 bashManual install from the tarball (any platform, including Windows)
# Download from the asset below, then:
npm install -g ./opencode-rich-presence-v3.1.8.tgz
opencode-rpc installWhy not npm install -g Khip01/opencode-rich-presence#v3.1.8?
npm v11 has a bug installing global git deps: the install
appears to succeed (added 1 package) but the
opencode-rpc binary is missing. Always install from a
local tarball. See
TROUBLESHOOTING.md
for the full story.
Upgrade
Once installed, use opencode-rpc update to upgrade:
opencode-rpc update # latest stable release tag
opencode-rpc update --stable # force install latest stable
opencode-rpc update --dev <branch> # latest commit on <branch>
opencode-rpc update --ref v3.1.8 # install a specific tag, branch, or SHA
opencode-rpc update --repo <fork> # install from a forkWhat's in v3.1.8
See CHANGELOG.md for full details.
v3.1.7
Installation
Stable (recommended for end users)
# Easiest path: one-liner curl installer. Works on
# Linux, macOS, and Windows (Git Bash / MSYS2 / Cygwin / WSL).
curl -fsSL https://raw.githubusercontent.com/Khip01/opencode-rich-presence/main/install.sh | bashPin to a specific version:
curl -fsSL https://raw.githubusercontent.com/Khip01/opencode-rich-presence/main/install.sh \
| ORP_VERSION=v3.1.7 bashIf you get HTTP 429 (rate-limited)
GitHub's raw CDN sometimes returns 429 Too Many Requests if
your IP has hit the unauthenticated rate limit (common on
shared networks, VPN exit nodes, or after many recent requests).
Two reliable fallbacks:
# Option A: jsDelivr CDN (mirrors GitHub via Cloudflare,
# usually a separate rate limit pool).
curl -fsSL https://cdn.jsdelivr.net/gh/Khip01/opencode-rich-presence@main/install.sh | bash
# Option B: use wget instead of curl (separate download path,
# often not affected when curl is).
wget -qO- https://raw.githubusercontent.com/Khip01/opencode-rich-presence/main/install.sh | bashIf both fail, download the tarball below and install manually
(any platform including Windows):
# Download from: https://github.com/Khip01/opencode-rich-presence/releases/latest
npm install -g ./opencode-rich-presence-v3.1.7.tgz
opencode-rpc installManual install from the tarball (any platform, including Windows)
# Download from the asset below, then:
npm install -g ./opencode-rich-presence-v3.1.7.tgz
opencode-rpc installWhy not npm install -g Khip01/opencode-rich-presence#v3.1.7?
npm v11 has a bug installing global git deps: the install
appears to succeed (added 1 package) but the
opencode-rpc binary is missing. Always install from a
local tarball. See
TROUBLESHOOTING.md
for the full story.
Upgrade
Once installed, use opencode-rpc update to upgrade:
opencode-rpc update # latest stable release tag
opencode-rpc update --stable # force install latest stable
opencode-rpc update --dev <branch> # latest commit on <branch>
opencode-rpc update --ref v3.1.7 # install a specific tag, branch, or SHA
opencode-rpc update --repo <fork> # install from a forkWhat's in v3.1.7
See CHANGELOG.md for full details.
v3.1.4-phase2
Installation
Stable (recommended for end users)
# Easiest path: use the CLI's built-in installer. It
# handles git ref syntax, works around npm v11's broken
# git-dep symlinks, and supports version pinning.
opencode-rpc update --ref v3.1.4-phase2
opencode-rpc install
# Or install via npm directly (zsh users: wrap in single quotes):
npm install -g 'Khip01/opencode-rich-presence#v3.1.4-phase2'
opencode-rpc installInstall from a specific branch (e.g. redesign/v3-daemon)
# DO NOT use 'npm install -g <url>#<branch>' for branches.
# npm v11 has a bug that creates a partial install without
# the opencode-rpc symlink. Use the CLI instead:
opencode-rpc update --ref redesign/v3-daemon
opencode-rpc install
# Track a branch for ongoing dev installs:
opencode-rpc update --dev redesign/v3-daemon
opencode-rpc installUpdate
opencode-rpc update # latest stable release tag
opencode-rpc update --stable # force install latest stable
opencode-rpc update --dev <branch> # latest commit on <branch>
opencode-rpc update --ref <ref> # specific ref (tag, branch, or SHA)
opencode-rpc update --repo <fork> # install from a forkWhat's in v3.1.4-phase2
See CHANGELOG.md for full details.
v2.1.1
Installation
Stable (recommended for end users)
# Pin to a specific version:
npm install -g Khip01/opencode-rich-presence#v2.1.1
# Or auto-resolve the latest stable matching ^v0:
npm install -g Khip01/opencode-rich-presence#semver:^v2.1.1
opencode-rpc installDev / bleeding-edge (developers only)
npm install -g Khip01/opencode-rich-presence
opencode-rpc installUpdate
opencode-rpc update # upgrade to latest stable tag
opencode-rpc update --dev # upgrade to latest commit on mainNote: npm install -g <repo>#<ref> clones the repo and installs
from there. The tarball attached to this release is provided as
a fallback for offline / air-gapped installs; the git URL is the
canonical install path.
What's in v2.1.1
See CHANGELOG.md for full details.
v2.1.0
Installation
Stable (recommended for end users)
# Pin to a specific version:
npm install -g Khip01/opencode-rich-presence#v2.1.0
# Or auto-resolve the latest stable matching ^v0:
npm install -g Khip01/opencode-rich-presence#semver:^2.0.0
opencode-rpc installDev / bleeding-edge (developers only)
npm install -g Khip01/opencode-rich-presence
opencode-rpc installUpdate
opencode-rpc update # upgrade to latest stable tag
opencode-rpc update --dev # upgrade to latest commit on mainNote: npm install -g <repo>#<ref> clones the repo and installs
from there. The tarball attached to this release is provided as
a fallback for offline / air-gapped installs; the git URL is the
canonical install path.
What's in v2.1.0
Distribution workflow change. Replaces GitHub Releases + tarball
with git-based npm install. Single source of truth = the repo.
Changed
- Install workflow: end users now install via
npm install -g Khip01/opencode-rich-presence#v2.1.0instead of downloading a tarball from a GitHub Release URL. The GitHub Releases workflow is preserved but its job-levelifcondition skips any tag containing-rc/-beta/-alpha; only stable tags create a GitHub Release (which now points users to the git install command and provides the tarball as a fallback for offline installs). - No more
-rc/-beta/-alphapre-release tags. Useopencode-rpc update --devto test a fix before tagging stable.
Updated
opencode-rpc updaterunsnpm install -g Khip01/opencode-rich-presence#<latest-tag>.- Added
opencode-rpc update --devfor developers: fetches the latest commit SHA onmainand runsnpm install -g Khip01/opencode-rich-presence#<sha>. - Removed the
--prerelease/--preflag fromopencode-rpc update.
See CHANGELOG.md for full details.
v2.0.9
Installation
Fresh install
npm install -g https://github.com/Khip01/opencode-rich-presence/releases/download/v2.0.9/opencode-rich-presence-v2.0.9.tgz
opencode-rpc installThe 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 updateOr reinstall manually:
npm install -g https://github.com/Khip01/opencode-rich-presence/releases/download/v2.0.9/opencode-rich-presence-v2.0.9.tgzMigrating from v1.0.0
v1.0.0 used bash scripts (install, uninstall, restart-discord.sh) and was Linux-only.
- Back up your old
~/.config/opencode/discord-config.jsonif you have one. - Run the fresh install command above.
- Run
opencode-rpc installto set up the new config file. - Restore your settings into the new config (App ID, presence templates).
- 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
- 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
SIGTERM200ms 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=SIGTERMimmediately after a handoff, killing the new leader's worker - Fixed by polling
child.exitCodeandchild.signalCodeand 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
lastActivitywas 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, andmessage.part.updatednow opt out of handoff- Only
chat.message,permission.asked, andpermission.repliedstill request handoff - Agent-side events still
markActivebut 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-handoffwhen it receiveschat.messageor 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 lossshutdownWorker()is distinct fromdestroy()(which is permanent) so the instance can re-acquire leadership later
Chore: docs
docs/ARCHITECTURE.mdrewrites the Multi-instance Coordinator sectiondocs/TROUBLESHOOTING.mdadds a root cause entry for "idle leader shows stale presence"CHANGELOG.mdadds v2.0.7 entry- Project
AGENTS.mdadds 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.
v2.0.8
Installation
Fresh install
npm install -g https://github.com/Khip01/opencode-rich-presence/releases/download/v2.0.8/opencode-rich-presence-v2.0.8.tgz
opencode-rpc installThe 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 updateOr reinstall manually:
npm install -g https://github.com/Khip01/opencode-rich-presence/releases/download/v2.0.8/opencode-rich-presence-v2.0.8.tgzMigrating from v1.0.0
v1.0.0 used bash scripts (install, uninstall, restart-discord.sh) and was Linux-only.
- Back up your old
~/.config/opencode/discord-config.jsonif you have one. - Run the fresh install command above.
- Run
opencode-rpc installto set up the new config file. - Restore your settings into the new config (App ID, presence templates).
- 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
- 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
SIGTERM200ms 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=SIGTERMimmediately after a handoff, killing the new leader's worker - Fixed by polling
child.exitCodeandchild.signalCodeand 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
lastActivitywas 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, andmessage.part.updatednow opt out of handoff- Only
chat.message,permission.asked, andpermission.repliedstill request handoff - Agent-side events still
markActivebut 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-handoffwhen it receiveschat.messageor 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 lossshutdownWorker()is distinct fromdestroy()(which is permanent) so the instance can re-acquire leadership later
Chore: docs
docs/ARCHITECTURE.mdrewrites the Multi-instance Coordinator sectiondocs/TROUBLESHOOTING.mdadds a root cause entry for "idle leader shows stale presence"CHANGELOG.mdadds v2.0.7 entry- Project
AGENTS.mdadds 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.
v2.0.8-rc5
Installation
Fresh install
npm install -g https://github.com/Khip01/opencode-rich-presence/releases/download/v2.0.8-rc5/opencode-rich-presence-v2.0.8-rc5.tgz
opencode-rpc installThe 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 updateOr reinstall manually:
npm install -g https://github.com/Khip01/opencode-rich-presence/releases/download/v2.0.8-rc5/opencode-rich-presence-v2.0.8-rc5.tgzMigrating from v1.0.0
v1.0.0 used bash scripts (install, uninstall, restart-discord.sh) and was Linux-only.
- Back up your old
~/.config/opencode/discord-config.jsonif you have one. - Run the fresh install command above.
- Run
opencode-rpc installto set up the new config file. - Restore your settings into the new config (App ID, presence templates).
- 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
- 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
SIGTERM200ms 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=SIGTERMimmediately after a handoff, killing the new leader's worker - Fixed by polling
child.exitCodeandchild.signalCodeand 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
lastActivitywas 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, andmessage.part.updatednow opt out of handoff- Only
chat.message,permission.asked, andpermission.repliedstill request handoff - Agent-side events still
markActivebut 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-handoffwhen it receiveschat.messageor 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 lossshutdownWorker()is distinct fromdestroy()(which is permanent) so the instance can re-acquire leadership later
Chore: docs
docs/ARCHITECTURE.mdrewrites the Multi-instance Coordinator sectiondocs/TROUBLESHOOTING.mdadds a root cause entry for "idle leader shows stale presence"CHANGELOG.mdadds v2.0.7 entry- Project
AGENTS.mdadds 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.
v2.0.8-rc4
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 installThe 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 updateOr 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.tgzMigrating from v1.0.0
v1.0.0 used bash scripts (install, uninstall, restart-discord.sh) and was Linux-only.
- Back up your old
~/.config/opencode/discord-config.jsonif you have one. - Run the fresh install command above.
- Run
opencode-rpc installto set up the new config file. - Restore your settings into the new config (App ID, presence templates).
- 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
- 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
SIGTERM200ms 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=SIGTERMimmediately after a handoff, killing the new leader's worker - Fixed by polling
child.exitCodeandchild.signalCodeand 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
lastActivitywas 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, andmessage.part.updatednow opt out of handoff- Only
chat.message,permission.asked, andpermission.repliedstill request handoff - Agent-side events still
markActivebut 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-handoffwhen it receiveschat.messageor 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 lossshutdownWorker()is distinct fromdestroy()(which is permanent) so the instance can re-acquire leadership later
Chore: docs
docs/ARCHITECTURE.mdrewrites the Multi-instance Coordinator sectiondocs/TROUBLESHOOTING.mdadds a root cause entry for "idle leader shows stale presence"CHANGELOG.mdadds v2.0.7 entry- Project
AGENTS.mdadds 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.