plugins: event subscribers fire once per client connection — N× side effects, undocumented #56290

Activity

1. opencode-agent commented on Oct 17, 2026

   

   opencode-agentBot

   on Oct 17, 2026 – with OpenCode Agent

   Contributor

   More actions

   Thanks for the detailed report. I reproduced this on 2.0.30, and it still happens on the latest dev (512165c).

   In my testing the multiplier is the number of loaded project directories (locations) in the server process, not the number of client connections:

   • I used a global local plugin that logs an instance id in setup() and on each session.created from ctx.event.subscribe({}), and ran one opencode serve.
   • I loaded three different directories, then created one session in the first. setup() ran 3 times, and all 3 instances received that same session.created.
   • When I loaded the same directory three times instead, there was only 1 instance and 1 delivery.

   From the code, plugins are started once per location, but ctx.event.subscribe() gives each instance the events from every location. That's why a notifier fires once per open project. Your globalThis claim map works as a workaround for now.

   The script below reproduces it without a model.

   Related: #54140 (instances pile up across config reloads, with the same N× symptom but a different cause) and #51003 (MCP servers started once per loaded directory).

   Reproduction script (repro.sh)

   #!/usr/bin/env bash
   # Repro for #56290: a plugin's setup() runs once per loaded location in one server
   # process, and every instance's ctx.event.subscribe() receives every event.
   # Usage: ./repro.sh            (uses `opencode` from PATH)
   #        OC="bun --conditions=browser --preload=<repo>/packages/tui/node_modules/@opentui/solid/scripts/preload.js <repo>/packages/cli/src/index.ts" ./repro.sh
   set -u
   OC=${OC:-opencode}
   ROOT=$(mktemp -d /tmp/opencode/repro56290.XXXX)
   export HOME=$ROOT/home XDG_CONFIG_HOME=$ROOT/home/.config XDG_DATA_HOME=$ROOT/home/.local/share \
          XDG_STATE_HOME=$ROOT/home/.local/state XDG_CACHE_HOME=$ROOT/home/.cache
   LEDGER=$ROOT/ledger.log; export LEDGER
   mkdir -p $XDG_CONFIG_HOME/opencode/plugins $ROOT/p1 $ROOT/p2 $ROOT/p3
   for d in p1 p2 p3; do git -C $ROOT/$d init -q; done
   cat > $XDG_CONFIG_HOME/opencode/plugins/echo-test.js <<'JS'
   import { appendFileSync } from "node:fs"
   export default {
     id: "echo-test",
     async setup(ctx) {
       const id = Math.random().toString(36).slice(2, 8)
       appendFileSync(process.env.LEDGER, `setup ${id}\n`)
       void (async () => {
         for await (const event of ctx.event.subscribe({})) {
           if (event?.type === "session.created")
             appendFileSync(process.env.LEDGER, `event ${id} ${event.type} ${event.data?.sessionID ?? event.data?.id ?? JSON.stringify(event.data).slice(0, 60)}\n`)
         }
       })()
     },
   }
   JS
   export OPENCODE_PASSWORD=repro
   PORT=48${RANDOM:0:3}
   (cd $ROOT/p1 && $OC serve --port $PORT > $ROOT/server.log 2>&1) &
   SRV=$!
   for i in $(seq 60); do curl -s -o /dev/null http://127.0.0.1:$PORT/ && break; sleep 1; done
   # touch three different project directories (as three clients would)
   for d in p1 p2 p3; do
     curl -s -u opencode:repro -H "x-opencode-directory: $ROOT/$d" "http://127.0.0.1:$PORT/api/agent" > /dev/null
   done
   sleep 5
   echo "--- creating ONE session in p1"
   (cd $ROOT/p1 && $OC api --server http://127.0.0.1:$PORT POST /api/session -d '{}' | head -c 300; echo)
   sleep 3
   echo "--- ledger"; cat $LEDGER
   echo "--- setups: $(grep -c ^setup $LEDGER)  deliveries of the one session.created: $(grep -c ^event $LEDGER)"
   kill $SRV 2>/dev/null; wait 2>/dev/null

   Run it: bash repro.sh
2. opencode-agent

   added

   reproduced

   on Oct 17, 2026
3. herrtreas commented on Nov 5, 2026

   

   herrtreas

   on Nov 5, 2026

   More actions

   Another effect of this, seen on 2.0.29 and 2.2.5: a session's hooks (session.prompt, session.title, tool.execute.*) fire only in the plugin instance for the session's own location, but its events reach every instance. A plugin that pairs hooks with events therefore misjudges other locations' sessions. In our case, an instance that never saw the session.title hook took a generated title for a name the person chose.

   Our workaround is to ignore events whose location (on session.created and session.moved, or from session.get) isn't the instance's own ctx.location, compared exactly, which is how 2.0.29 keys instances. The fixes in #56346 and #57186 would make that unnecessary.