[Bug] Goal completion verifier enters infinite loop on temporally-gated goals, burning ~30M+ tokens (~+) in system-reminder cycles

Summary

When a session goal (/goal) includes requirements that are structurally impossible for a code agent to satisfy (e.g., "use the app for 2-3 days", "wait 30 days for telemetry"), the goal completion verifier enters an infinite loop: each agent response — including empty ones — triggers a new system reminder asking the agent to "continue working toward the active session goal." The verifier's own output explicitly acknowledges the impossibility ("these gates are genuinely impossible to satisfy in a code session") but still asks for continuation, creating an unstoppable cycle.

In our case, the loop ran ~40+ iterations, consuming an estimated 30M+ tokens (~800k per cycle for the verifier's system context + agent response overhead) before the user manually intervened. This represents significant API cost and session-time waste for a scenario the runtime should have detected and halted.

Environment

• ZCode Desktop 3.12.3 (Linux x64, Fedora 44)
• Session type: long-running coding session with a /goal objective
• Goal definition: GOAL.md with phases F1-F5, where F5 was gated by "30 days of telemetry after the production flag flip"
• All code deliverables were completed, pushed, and deployed before the loop started

Reproduction

1. Define a /goal that mixes code deliverables with temporal/operational gates (e.g., "deploy the app, use it for 30 days, then call function X")
2. Complete all code work (agent finishes implementation, deployment, etc.)
3. The agent reports the remaining steps are impossible for a code agent (temporal/human-only)
4. The completion verifier fires a system reminder: "Continue working toward the active session goal… Next action: [the impossible step]"
5. Agent responds (anything from a full explanation to an empty string)
6. Repeat steps 4-5 indefinitely (~40+ times observed)

Evidence

Verifier output acknowledging impossibility but still requesting continuation (repeated verbatim ~40x):

Reason: …these gates are genuinely impossible to satisfy in a code session
because they depend on human interaction with the app GUI along days/weeks
and the passage of calendar time…
Next action: Use the app SoarCode normally for 2-3 days…

Agent's progressively minimal responses (all triggered the next cycle):

Iteration	Agent response	Tokens consumed by system context
1-5	Full explanations (~200 words)	~800k each
6-10	Short statements ("impossible", "blocked by time")	~800k each
11-20	Single words ("end", "nothing")	~800k each
21-40+	Empty (​)	~800k each

Cumulative impact:

• ~40+ verifier cycles × ~800k tokens of system-context overhead = ~32M tokens
• Estimated cost at Claude/GLM-4.5 rates: significant unnecessary expense
• Session duration extended by ~30 minutes of pure loop time
• User's weekly token quota significantly depleted

Root Cause Analysis

The verifier evaluates goal completion as a binary (complete/incomplete) without a "blocked" or "agent-unreachable" state. When a goal includes requirements the agent cannot execute (temporal gates, human-only actions, GUI interactions), the verifier:

1. Correctly identifies them as unfulfilled ✓
2. Correctly identifies them as impossible for a code agent ✓
3. Still requests continuation ✗ (the bug)

The agent is trapped: any response (or non-response) triggers the next verification cycle. There is no mechanism to:

• Mark a goal as blocked or deferred
• Signal "all agent-completable work is done; remaining items are owner-actions"
• Break the loop from the agent side

Suggested Fix

Option A: Add a "blocked" goal state

Allow the agent (or the verifier itself) to transition the goal from active to blocked when:

• All code deliverables are verified complete
• Remaining requirements are identified as non-agent-executable (temporal/human-only)
• The verifier itself acknowledges the impossibility in its output

Option B: Detection in the verifier

If the verifier's analysis concludes "these gates are genuinely impossible to satisfy in a code session," it should stop the loop and mark the goal as partially-complete (blocked on external factors) rather than requesting continuation.

Option C: Loop detection

If the verifier has sent the same "Next action" N consecutive times (e.g., 3+) with no change in the goal state, auto-halt and surface to the user.

Option D: Goal definition validation

At /goal definition time, warn or require explicit opt-in for goals that mix agent-completable and human-only deliverables. The GOAL.md format could separate:

## Agent deliverables (auto-completable)
## Owner gates (not agent-completable; blocks goal completion until manually cleared)

Impact

• Severity: Financial (unnecessary token consumption) + UX (session stuck in loop)
• Frequency: Any session with a long-running goal that includes deployment/telemetry/temporal gates
• Workaround: None from the agent side (any response continues the loop); user must manually interrupt the session

---

Filed: 2026-09-19, zai-org/feedback — observed on ZCode Desktop 3.12.3, Linux x64

Start at the /goal entry point and inspect the completion verifier and its session-reminder cycle described in the report. Reproduce the behavior with a GOAL.md containing a temporal gate, then verify that an impossible or unchanged next action no longer causes repeated cycles and that the session surfaces a stoppable blocked state.