Skip to content

Releases: Khip01/opencode-rich-presence

v3.1.9

Choose a tag to compare

@github-actions github-actions released this 01 Aug 10:36
42f6dfe

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 | bash

Pin to a specific version:

curl -fsSL https://raw.githubusercontent.com/Khip01/opencode-rich-presence/main/install.sh \
  | ORP_VERSION=v3.1.9 bash

Manual 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 install

Why 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 fork

What's in v3.1.9

See CHANGELOG.md for full details.

v3.1.8

Choose a tag to compare

@github-actions github-actions released this 10 Jul 16:42
716acbc

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 | bash

Pin to a specific version:

curl -fsSL https://raw.githubusercontent.com/Khip01/opencode-rich-presence/main/install.sh \
  | ORP_VERSION=v3.1.8 bash

Manual 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 install

Why 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 fork

What's in v3.1.8

See CHANGELOG.md for full details.

v3.1.7

Choose a tag to compare

@github-actions github-actions released this 09 Jul 00:42
ee4b960

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 | bash

Pin to a specific version:

curl -fsSL https://raw.githubusercontent.com/Khip01/opencode-rich-presence/main/install.sh \
  | ORP_VERSION=v3.1.7 bash

If 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 | bash

If 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 install

Manual 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 install

Why 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 fork

What's in v3.1.7

See CHANGELOG.md for full details.

v3.1.4-phase2

Choose a tag to compare

@github-actions github-actions released this 07 Jul 23:14
7004fb3

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 install

Install 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 install

Update

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 fork

What's in v3.1.4-phase2

See CHANGELOG.md for full details.

v2.1.1

Choose a tag to compare

@github-actions github-actions released this 04 Jul 14:20
v2.1.1
9c97197

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 install

Dev / bleeding-edge (developers only)

npm install -g Khip01/opencode-rich-presence
opencode-rpc install

Update

opencode-rpc update                  # upgrade to latest stable tag
opencode-rpc update --dev            # upgrade to latest commit on main

Note: 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

Choose a tag to compare

@Khip01 Khip01 released this 04 Jul 06:20
26aa17d

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 install

Dev / bleeding-edge (developers only)

npm install -g Khip01/opencode-rich-presence
opencode-rpc install

Update

opencode-rpc update                  # upgrade to latest stable tag
opencode-rpc update --dev            # upgrade to latest commit on main

Note: 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.0 instead of downloading a tarball from a GitHub Release URL. The GitHub Releases workflow is preserved but its job-level if condition 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 / -alpha pre-release tags. Use opencode-rpc update --dev to test a fix before tagging stable.

Updated

  • opencode-rpc update runs npm install -g Khip01/opencode-rich-presence#<latest-tag>.
  • Added opencode-rpc update --dev for developers: fetches the latest commit SHA on main and runs npm install -g Khip01/opencode-rich-presence#<sha>.
  • Removed the --prerelease / --pre flag from opencode-rpc update.

See CHANGELOG.md for full details.

v2.0.9

Choose a tag to compare

@github-actions github-actions released this 04 Jul 03:27
35227d6

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 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.9/opencode-rich-presence-v2.0.9.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.

v2.0.8

Choose a tag to compare

@github-actions github-actions released this 04 Jul 03:10
b44f0c0

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 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/opencode-rich-presence-v2.0.8.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.

v2.0.8-rc5

v2.0.8-rc5 Pre-release
Pre-release

Choose a tag to compare

@github-actions github-actions released this 04 Jul 02:29
91107b6

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 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-rc5/opencode-rich-presence-v2.0.8-rc5.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.

v2.0.8-rc4

v2.0.8-rc4 Pre-release
Pre-release

Choose a tag to compare

@github-actions github-actions released this 04 Jul 01:18
abf0fe9

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.