Repository navigation
V2: reliable host-owned stop/clear UX when an agent finishes a Loop job #175
Description
Observation
The Reddit report says telling the model to execute /loop-clear did not stop the job. A model writing a slash command in chat is not the same as the user invoking OpenCode's native host command. Separately, a real exFAT user reported editing persisted state to stop an idle job.
Goal
Provide a safe, discoverable, model-independent stop path, including clear explanation of which actor can stop a job. Investigate whether an explicitly authorized host-owned agent completion signal/tool should be exposed for the current Loop job without broadening capabilities or bypassing foreground/Goal reservation.
Acceptance
/loop-statusdocuments job identity, infinite/completion mode, and the exact native user stop operation.- Confirm
/loop-stop,/loop-clearcan stop scheduled and queued work even when a model suggests a command; no shadow Markdown prompt commands. - If adding a tool, scope to the currently Loop-owned run and job/session, require host-issued one-use authority, reject arbitrary prompts / other sessions / stale generations; never permit Goal lifecycle authority via Loop.
- Tests cover before dispatch, queued-undelivered cancellation, delivered turn, restart, foreground interruption, Desktop/TUI/remote differences.
- Keep default unlimited scheduling unchanged; cross-reference checklist-stop issue.
Activity
fix(v2): show checklist completion and actionable native stop controls (
docs(v2): add native checklist stop and clarify user slash controls (#…
test(v2): prove checklist stops before second prompt and enforces ver…
fix(v2): preserve exact empty-status compatibility while showing stop…
feat(v2): host-checked Markdown checklist stop with verified file dig…
ByBrawe commentedon Oct 30, 2026
Maintenance-scope decision (2026-10-30): we are keeping stop/clear host-owned. A model printing
/loop-clearis not a host command; existing user-invoked/loop-stop,/loop-clearand/loop-statusare the supported safe controls, with host-level tests and the distinction documented in 0.6.9/0.6.10 notes. We will not add an assistant-invoked stop tool or capability-granting agent workflow during the final standalone release: doing so would introduce new authorization, race and cross-session risks without an independently proven safe design. Closing the optional feature request not planned, not claiming a model can execute the slash command.