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

Aberta
  • Algo errado?
#1,663 0 comentários 0 reações 0 responsáveis Ver no GitHub

Mantenedores costumam responder em até 1 dia

Ninguém assumiu esta issue ainda.

Avaliação

Dificuldade
4/5
Tempo estimado
3-5 dias
Facilidade para iniciantes
48/100
Tipo de issue
Bug
Clareza
Claramente especificada
Status de atividade
Ativa
Stack de tecnologia
bash, shell
Domínio
cli, developer-experience

Direção de pesquisa

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.

Escrita pelo modelo de indexação a partir do texto da issue.

Descrição

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.

Linguagem predominante
Shell
Estrelas
1.5k
Forks
156
Merge médio
14h 56min
PRs com merge (30d)
203

Preparar o ambiente

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de fujibee/agmsg

Todas as issues de fujibee/agmsg

Issues semelhantes

Mais issues de Shell/Bash

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.