Bug: autonomous tool loop intermittently stops after successful tool result, especially during tracked tasks

[Daxiongmao87]

Summary

The autonomous tool execution loop intermittently stops after a tool completes successfully. The UI remains parked on the final tool result (for example, “Script executed successfully”) instead of scheduling the next assistant turn.

This appears more frequently during workflows using manage_task, likely because tracked tasks require additional tool boundaries for progress updates, action execution, verification, task completion, and end_loop.

Observed behavior

During a multi-step journal cleanup task:

1. A tracked task was active through manage_task.
2. Several document edits and deletions completed successfully.
3. A final run_javascript verification returned valid data:
   • the retained journal existed;
   • it still had 8 pages;
   • the obsolete UUID reference was absent;
   • the replacement note was present.
4. The tool displayed “Script executed successfully.”
5. No subsequent assistant turn was scheduled.
6. The task tracker remained unfinished even though the underlying work had completed.
7. The user had to send another message to recover control.

A related symptom occurred earlier in the same conversation: after an interrupted tracked task, a later manage_task update returned “No active task to update.” This suggests the active task lifecycle may become orphaned or be lost when the autonomous loop stops unexpectedly.

Expected behavior

After any successful non-terminal tool result, the tool-loop handler should reliably schedule the next assistant/model turn so it can:

• process the result;
• continue to the next planned action;
• update or finish manage_task;
• call end_loop; and
• return control to the user cleanly.

A successful tool response should never become an implicit terminal state unless the assistant explicitly calls end_loop.

Actual behavior

The loop sometimes terminates or stalls immediately after a successful tool response. The raw tool result becomes the final visible state, with no summary, no task completion, and no end_loop call.

Reproduction steps

The issue is intermittent, but this pattern appears to trigger it more often:

1. Start an autonomous multi-step workflow with manage_task(action="start_task").
2. Perform several document operations.
3. Verify each operation with additional read/search/JavaScript calls.
4. Near the end of the workflow, execute a final run_javascript, read_document, or similar verification tool.
5. Observe that the tool returns successfully.
6. In affected runs, the system does not initiate the next assistant turn, leaving the tracked task incomplete.

Frequency

Intermittent, but reported as happening often, especially during tracked tasks.

Impact

• Users perceive the assistant as hung even though the tool action succeeded.
• Destructive or mutating workflows may complete without a final human-readable report.
• Visual task trackers remain incomplete or become orphaned.
• Users must manually prompt the assistant to continue.
• A resumed task may report “No active task to update.”
• Repeated recovery attempts can cause confusion about whether operations completed.

Suspected area

Likely in the post-tool-result continuation path in scripts/core/tool-loop-handler.js, particularly around:

• result processing after a successful tool call;
• scheduling the next model turn;
• determining whether a tool result is terminal;
• preserving active manage_task state across loop iterations; and
• cleanup/error paths that may return without either continuing or explicitly ending the loop.

Related but not duplicate: #147 tracks refactoring tool-loop-handler.js; it does not describe this post-tool continuation failure.

Suggested diagnostics / safeguards

• Add structured logging around every tool-loop state transition:
  • tool call received;
  • tool execution started/completed;
  • result appended to conversation;
  • next model turn scheduled;
  • loop explicitly ended.
• Assert that every successful non-end_loop tool result has exactly one continuation scheduled.
• Add a watchdog that detects an active autonomous loop with no scheduled continuation after result processing.
• Persist or recover active manage_task state when a loop is interrupted unexpectedly.
• Add an integration test with a tracked task containing multiple action/verification cycles followed by a final verification call.

Acceptance criteria

• A successful non-terminal tool call always results in another assistant turn.
• manage_task workflows reliably reach finish_task and end_loop unless the user interrupts or a terminal error occurs.
• Interrupted loops do not silently discard or orphan active task state.
• Automated coverage reproduces and guards against the final-tool-result stall.

[Daxiongmao87]

Additional timing evidence from a captured 2026-07-22 session

A timing-specific analysis of the exported Simulacrum interaction log found two more instances matching this issue. Both stopped immediately after successful, non-terminal tool results and resumed only after the user sent continue.

Reproduction A

• 3:28:32–3:28:33 PM: the assistant issued five repository searches for chase hazards.
• All five returned successful results; the final result arrived at 3:28:33 PM.
• No subsequent assistant turn was recorded.
• At 3:40:17 PM, after 11m 44s, the user sent continue.
• The next assistant turn arrived at 3:40:28 PM and continued the existing tracked task.

Reproduction B

• 4:01:24–4:01:26 PM: the assistant issued actor/document reads and a journal inventory request.
• Every result succeeded; the final list_documents result arrived at 4:01:26 PM.
• No subsequent assistant turn was recorded.
• At 4:08:45 PM, after 7m 19s, the user sent continue.
• The next assistant turn arrived at 4:08:59 PM and continued the workflow.
• Later in that resumed run, manage_task(update_task) returned No active task to update. The agent had to recreate the tracker, consistent with the task-lifecycle loss already described here.

Tool execution was not the delay

Across the captured session:

• 224 successful tool executions were measured.
• Median Tool → Result time: 0s.
• 90th percentile: 2s.
• Maximum: 4s.

The two affected tools had already returned successfully. The missing interval begins after result commitment, where _processLoopCycle() should call _getNextAIResponse() and return { action: 'continue', response, ... } to _runLoopIteration().

Important distinction from ordinary provider latency

The same log contains several 8–15-minute Result → Assistant gaps where an assistant turn eventually appeared without user intervention. Those may be long provider requests and should not automatically be classified as this issue.

For the two cases above, the observable signature is different: successful result → no autonomous assistant turn → manual continue required. No HAR was captured for those exact intervals, so current evidence cannot determine whether:

1. _getNextAIResponse() was never entered;
2. it was entered but remained pending or aborted while the outer processing lifecycle ended; or
3. it returned but the next loop iteration/UI update was lost.

Diagnostics needed to localize the break

Please add one correlated loopId/iteration timeline covering:

• tool_results_committed
• continuation_requested
• api_request_started
• api_request_finished | api_request_failed | api_request_aborted
• loop_iteration_advanced
• assistant_emitted
• process_status_ended, including an explicit terminal reason

Also assert that every successful non-end_loop result reaches exactly one of:

• a scheduled continuation;
• a recorded user cancellation;
• a typed terminal failure; or
• an explicit loop-limit termination.

The current interaction export does not record API request boundaries, cancellation state, loop iteration IDs, or the reason processing ended, so it cannot distinguish the three breakpoints above after the fact.

This evidence is intentionally limited to the two manual-recovery stalls. A separate timing finding—volatile asset-index counts changing tool descriptions and invalidating prompt-cache stability—can increase request latency, but it does not by itself explain why these two loops required continue.