Fix: Resolve JSON malformation causing infinite loops and TypeError

[gdeyoung]

Summary

Fixed multiple critical bugs causing JSON malformation, infinite loops, and TypeError crashes in Agent Zero.

Issues Fixed

1. JSON Object Extraction Bug (rfind)

File: python/helpers/extract_tools.py - Used rfind to find LAST closing brace instead of matching one
Fix: Proper nested brace tracking using depth counter

2. Escape Handling Logic Error

File: python/helpers/extract_tools.py - Escaped quotes not toggling in_string flag
Fix: Proper check for escaped quotes

3. No Loop Protection

File: agent.py - No protection against consecutive misformat errors
Fix: Added consecutive_misformat counter with 5-attempt limit + HandledException

4. TypeError: tool_args must be a mapping

File: agent.py - .get() returns string if key exists with string value
Fix: isinstance(tool_args, dict) validation

[gdeyoung]

Additional Fix v1.2 - HandledException Shadowing

Issue Found

A duplicate local class definition of HandledException in agent.py was shadowing the imported class from python.helpers.errors. This caused:

• isinstance(exception, HandledException) check to fail in handle_critical_exception
• Unhandled exceptions causing crashes instead of graceful loop termination

Root Cause

• Line 36: from python.helpers.errors import RepairableException, HandledException ✅ (import)
• Line 353: class HandledException(Exception): pass ❌ (duplicate local definition)

Fix Applied

Removed the duplicate class definition (lines 349-355) in agent.py. Now uses only the imported HandledException from errors.py.

Files Changed

• agent.py: Removed duplicate HandledException class definition

Verification

• Python syntax validated
• Import now works correctly (same class object used throughout)
• Exception handling now works as intended

---

Added: 2026-02-14

[longman391]

I can confirm this is a critical bug. I traced tool call failures across multiple chat sessions on my instance (v0.9.8.1, Claude Opus 4.6 via GitHub Copilot, 128k context) and found 105 empty tool_name failures in a single log file — all caused by the rfind bug in extract_json_object_string().

Evidence from my logs:

• Chat mYlPuJkf: 38 consecutive 'Tool not found' errors (messages 131-168) — the agent was stuck in an infinite loop of malformed output → error → retry
• The extract_json_object_string() function grabs everything between the first { and last }, which means incidental curly braces in LLM output (file paths like /restore/{backup_id}/, inline JSON examples, etc.) get misinterpreted as tool calls with empty tool_name
• I verified this by testing DirtyJson directly: input 'The backup is at /restore/{backup_id}/files' parses to {'backup_id': ''} with no tool_name → triggers 'Tool not found'

Additional issue not covered by this PR: The LLM frequently hallucinates tool names from training data instead of using the actual tool names in the system prompt:

• code_execution instead of code_execution_tool
• web_search instead of search_engine
• browser_tool instead of browser_agent
• response_tool / message_tool instead of response
• terminal instead of code_execution_tool

A simple alias mapping in get_tool() would catch these. Happy to submit a PR for that.

The consecutive misformat counter in this PR would have prevented the 38-message infinite loop. Please consider merging this — it's a significant stability improvement.