create_goal retried 10x in ~7s with no backoff after "already has a non-closed goal" error

[sergiofspedro]

Bug

When /goal <objective> is invoked and the agent's first create_goal call succeeds, the very next turn sometimes calls create_goal again for the same session. This correctly fails with "cannot create a new goal because this session already has a non-closed goal" — but the agent doesn't adapt to that error. It retries the same failing call repeatedly, with no backoff and no apparent ceiling, until the session is manually cancelled.

Repro (exact timeline, from server logs)

16:34:20.104  [tool] done tool=create_goal   <- succeeds
16:34:20.235  loop step=1
16:34:20.922  loop step=2
16:34:21.527  loop step=3
16:34:22.232  loop step=4
16:34:23.216  loop step=5
16:34:24.015  loop step=6
16:34:24.654  loop step=7
16:34:25.257  loop step=8
16:34:26.028  loop step=9
16:34:26.882  loop step=10
16:34:27.018  cancel                         <- manually cancelled by the user

10 loop iterations in 6.78 seconds (~0.7s apart), with no successful tool call logged between step 1 and the cancel — consistent with the agent repeatedly attempting (and failing) the same create_goal call. Confirmed via direct log inspection, not just symptom-matching. auto_continue was true at the time; the plugin's own documented safeguards (max_auto_turns: 25, min_continue_interval_seconds: 3, max_no_progress_turns: 2) did not prevent this — 10 rapid-fire turns in under 7 seconds is inconsistent with a 3-second minimum continue interval, and well under the 25-turn ceiling so it wasn't caught by that either.

Had the user not manually cancelled, there's no evidence anything would have stopped this session — a separate, unrelated test earlier the same day (via opencode run headless mode, different trigger) reached 254 rapid-fire tool-call iterations before being killed, so this class of runaway is not self-limiting once started.

Impact

This makes auto_continue: true unsafe for genuinely unattended use (e.g. an overnight autonomous session with nobody present to cancel) — which is the plugin's stated purpose ("keep working toward one explicit objective until it is complete, blocked, or cleared" / "session.idle continuation"). We've had to run with auto_continue: false as a result, which defeats the plugin's core feature.

Suggested directions

• When create_goal fails because a goal already exists, the continuation logic should recognize the existing goal (or call get_goal) instead of retrying create_goal blindly.
• min_continue_interval_seconds doesn't appear to be enforced for this specific retry path — worth checking whether error-triggered continuations bypass the normal continuation-scheduling code path that the interval guards.

Environment

OpenCode 1.18.15, plugin installed via opencode.jsonc:

["@prevalentware/opencode-goal-plugin", { "auto_continue": true }]