Agent loop 90s timeout too short for multi-tool terminal workflows

[Bahtya]

Summary

The agent loop has a hardcoded 90-second timeout per message processing cycle. When using terminal tools via WebSocket, multi-step workflows (create session → send input → wait → read output → capture screen → kill session) consistently exceed this limit because:

1. Each tool call requires a separate LLM inference round-trip (~5-10s each with glm-5-turbo)
2. The agent makes 5-8 tool calls per terminal test workflow
3. Agent reasoning/planning between tool calls adds further latency

Steps to Reproduce

1. Start kestrel gateway with WebSocket channel
2. Send a message requiring multi-step terminal interaction, e.g.:

   "Create a terminal session, run echo hello, wait 3s, capture screen, kill session"

3. Observe the agent's response after ~90s: ⏳ Processing your message took too long (90s limit). Please try again later.

Impact

• Agent cannot complete terminal tool workflows that require 5+ sequential tool calls
• wait_for_screen_change and read_output with timeouts consume precious seconds
• The 90s limit was likely designed for simple chat interactions, not tool-heavy workflows

Evidence

End-to-end WS tests with v0.10.4:

• T1_basic_shell: Hit 90s timeout after ~6 tool calls
• T2_screen_change: Hit 90s timeout
• T3_resize: Hit 90s timeout after creating 3 sessions and making ~15 tool calls

All 3 tests returned ⏳ Processing your message took too long (90s limit). Please try again later.

Suggested Fix

1. Make the timeout configurable per channel or per tool
2. Increase the default to 180-300s for terminal tool workflows
3. Consider a "tool call budget" approach instead of a wall-clock timeout

Related

• terminal_capture_screen returns empty screen on Windows ConPTY #361 (capture_screen returns empty on Windows — timeout prevented full diagnosis)