opencode: monitor delivery never starts on its own — the rule file is not loaded, and the watcher's owner never matches the actas lock

Offen
  • Stimmt etwas nicht?
#1,663 0 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 1 Tag

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
4/5
Geschätzter Aufwand
3-5 Tage
Anfängerfreundlichkeit
48/100
Issue-Typ
Bug
Klarheit
Klar beschrieben
Aktivitätsstatus
Aktiv
Tech-Stack
bash, shell
Bereich
cli, developer-experience

Rechercherichtung

Start with scripts/drivers/types/opencode/type.conf, the generated .opencode/rules/agmsg.md, the OpenCode skill at ~/.config/opencode/skills/agmsg/SKILL.md, and the watch.sh and actas-claim.sh owner handling; compare these with OpenCode 1.19's instruction loading and the sentinel launch environment described in the report. Reproduce with the listed opencode run prompt and the minimal steps, then check how the owner tokens differ. Done when monitor instructions load, the claim and watcher agree on the owner, and the role filtered watcher starts for the reproduction.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

Environment

  • agmsg v1.5.3-4-ge3a9325 (the first observation was on 2026-10-15, with the install from that day)
  • OpenCode 1.19.0 (V1 TUI), opencode-sentinel 0.1.5
  • Linux (WSL2), herdr terminal driver
  • Model: a local Qwen model behind an OpenAI-compatible endpoint
  • Team: one OpenCode seat (oc-worker, delivery monitor) next to Claude Code and Codex seats

Summary

In monitor mode, a fresh OpenCode session does not start an inbox watcher by itself. When the model does start one with the rule's command, watch.sh refuses the pair, because the watcher and actas-claim.sh end up with different owner tokens. The only way we found to get delivery is to read owner= from the role-session record and pass it to watch.sh by hand.

1. .opencode/rules/agmsg.md is not loaded by OpenCode

delivery.sh set monitor opencode <project> writes <project>/.opencode/rules/agmsg.md (hooks_file in scripts/drivers/types/opencode/type.conf). OpenCode 1.19 does not load that path. Its instruction loader reads AGENTS.md, CLAUDE.md and CONTEXT.md, the global ~/.config/opencode/AGENTS.md, and whatever the config lists under instructions. Nothing in agmsg adds the rule file to instructions.

Check: in the project, opencode run "Do not use any tools. Does your system prompt contain a section titled 'agmsg Integration Rule'? Answer YES or NO." answers NO. The same question about a file listed under instructions answers YES and quotes it.

Effect: the "Real-time inbox watcher" step never reaches the model. The installed ~/.config/opencode/skills/agmsg/SKILL.md does not cover it either. Its actas steps are identities → join → set FROM → report, with no actas-claim.sh and no watcher. In our session the model did not start a watcher after actas, and a reviewer's LWPASS sat unread until someone poked the seat.

2. The watcher's owner token never matches the lock taken by actas-claim.sh

  • The model runs actas-claim.sh through OpenCode's bash tool, where SENTINEL_SESSION_ID is unset (echo "${SENTINEL_SESSION_ID:-(unset)}" prints (unset)). Whether the model passes - or "${SENTINEL_SESSION_ID:--}", agmsg_normalize_instance_id produces -.<opencode pid>, and the lock owner becomes, for example, -.12345.
  • The rule's watcher command is watch.sh "${SENTINEL_SESSION_ID:--}" <project> opencode. opencode-sentinel spawns it with SENTINEL_SESSION_ID set to the OpenCode session id (src/lib/watcher.ts: env: { ...process.env, SENTINEL_SESSION_ID: params.sessionID }), so the watcher's owner is derived from ses_…, not from -.
  • Passing a literal - to watch.sh does not help either: line 60 maps - to empty, and line 111 then mints agmsg-<uuid>.

Observed (sentinel's stderr log, 2026-10-15):

agmsg watch: not serving these pairs (held by another session, or unverified): example-team/oc-worker(-.12345)

Minimal reproduction

  1. Install opencode-sentinel. Join an OpenCode seat to a team, then delivery.sh set monitor opencode <project>.
  2. Start opencode, then $agmsg actas <name>.
  3. Expected: a watcher starts and messages sent to <name> stream in. Actual: no watcher starts (1). If you ask the model to start the rule's command through sentinel_monitor, it exits with "not serving these pairs" (2).

Workaround we use

After actas-claim.sh "$(pwd)" opencode <name> -, read owner= from ~/.agents/skills/agmsg/run/role-session.<team>__<name>. Then start watch.sh '<owner>' <project> opencode <name> through sentinel_monitor. We put this procedure in a file listed under instructions. With it, a test message was answered within 3 seconds.

Possible directions (for discussion)

  • Register the rule file under instructions in the project's OpenCode config, or move its content to a location OpenCode loads.
  • Make actas-claim.sh and the sentinel-launched watch.sh derive the same owner for opencode, for example by not taking SENTINEL_SESSION_ID from the watcher's environment, or by having watch.sh normalize - the way actas-claim.sh does. Add the claim and the role-filtered watcher (4th argument) to the OpenCode skill's actas steps.

Related: #1462 (OpenCode V2 changes; this report is about V1 1.19).

This report was drafted with an AI coding assistant (Claude Code) from our own session logs and the agmsg sources. I checked the observations and quoted output against the logs before filing.

Vorherrschende Sprache
Shell
Sterne
1.5k
Forks
156
Ø Merge
14 Std. 56 Min.
Gemergte PRs (30 T.)
203

Entwicklungsumgebung

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus fujibee/agmsg

Alle Issues in fujibee/agmsg

Ähnliche Issues

Weitere Issues zu Shell/Bash

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.