Repro
$ agentctl list -a | grep af7d0a1a
af7d0a1a running opencode ohm/moonshotai/Kimi-K2.6 ~/code/mono-auto-ENG-10311 52894 1m ago ...
$ agentctl status af7d0a1a
ID af7d0a1a
Status running
...
$ agentctl stop af7d0a1a
Session not found: af7d0a1a-4933-4441-8f80-9180d198caf4
$ agentctl stop af7d0a1a --force
Session not found: af7d0a1a-4933-4441-8f80-9180d198caf4
$ agentctl stop af7d0a1a-4933-4441-8f80-9180d198caf4 --force
Session not found: af7d0a1a-4933-4441-8f80-9180d198caf4
Expected
stop should terminate any session that list -a and status agree is running.
Actual
stop reports 'Session not found' even though list and status (with the same short id) successfully resolve and report the session as running. Looks like a daemon/session-state mismatch where list and status read filesystem session metadata but stop queries a different (daemon) registry that lost the entry.
Impact
Blocks SOP-driven cleanup (in this case the Linear ticket-undelegation SOP). Forced fall-back to identifying the wrapper PID from list output and kill -TERM on the wrapper + child opencode process, plus manual worktree teardown. Doable but error-prone for newer agents.
Context
- agentctl version: $(agentctl --version) — current
- Adapter: opencode running ohm/moonshotai/Kimi-K2.6
- Wrapper script: ~/.agentctl/opencode-sessions/wrapper-af7d0a1a-4933-4441-8f80-9180d198caf4.sh
- Session was launched ~1 min before the stop attempt
- Same shell, same uid
Suggested
- Have
stop consult the same source of truth as list/status.
- If the daemon registry is missing the session, fall back to filesystem-derived PID and SIGTERM/SIGKILL the wrapper + child process group.
- Surface a clearer error like "daemon registry desynced from session metadata — try
agentctl prune then re-list" so the operator knows the right workaround.
Filed per AGENTS.md policy (file first, work around second). Encountered during the ENG-10311 undelegation SOP — worktree + branches were preserved; PR #11018 left open.
Repro
Expected
stopshould terminate any session thatlist -aandstatusagree is running.Actual
stopreports 'Session not found' even thoughlistandstatus(with the same short id) successfully resolve and report the session as running. Looks like a daemon/session-state mismatch wherelistandstatusread filesystem session metadata butstopqueries a different (daemon) registry that lost the entry.Impact
Blocks SOP-driven cleanup (in this case the Linear ticket-undelegation SOP). Forced fall-back to identifying the wrapper PID from
listoutput andkill -TERMon the wrapper + child opencode process, plus manual worktree teardown. Doable but error-prone for newer agents.Context
Suggested
stopconsult the same source of truth aslist/status.agentctl prunethen re-list" so the operator knows the right workaround.Filed per AGENTS.md policy (file first, work around second). Encountered during the ENG-10311 undelegation SOP — worktree + branches were preserved; PR #11018 left open.