Summary

OpenClaw 2026.6.1 / Codex app-server can stall after an inter-session sessions_send delegation times out. In the observed incident, the target session had already received a completed tool result, then remained stuck in model_call with no further assistant output or error. The caller then blocked on sessions_history. Other unrelated Codex sessions also stopped making progress.

Environment

• OpenClaw: 2026.6.1
• Runtime: OpenAI Codex
• Model: openai/gpt-5.5
• Model API: openai-chatgpt-responses
• Deployment: Docker container on NAS
• Node runtime in logs: 24.16.0

What happened

An agent delegated a task to another configured agent via sessions_send. The target agent did useful work and completed local tool calls, but after the final bash tool result the Codex app-server did not produce any next assistant item. Later diagnostics showed the target stuck in model_call. The requester also became stuck while waiting on sessions_history.

After this, multiple independent sessions also showed stale active work.

Timeline / Evidence

Times below are Asia/Shanghai on 2026-06-05.

• 18:18:24 gateway log:

  • subsystem: agent/embedded
  • message: codex dynamic tool call timed out
  • tool: sessions_send
  • timeout: 90000ms

• Target session trajectory:

  • session key: target agent main session
  • 18:18:19: bash tool result completed successfully after reading trip index
  • 18:18:28: next bash tool call started
  • 18:18:32: bash tool result completed successfully after reading a memory file
  • after that: no assistant output, no error, no final result

• 18:28:59 diagnostic:

  • requester session stalled
  • classification: blocked_tool_call
  • active tool: sessions_history
  • active tool age: ~622s

• 18:30:20 diagnostic:

  • target session stalled
  • classification: stalled_agent_run
  • active work: model_call
  • last progress: codex_app_server:request:item/tool/call:response
  • last progress age: ~604s

• 18:30:20 diagnostic also reported unrelated sessions stalled:

  • another agent session stalled in model_call
  • a cron-backed main session stalled in bash

This suggests the failure is broader than the original sessions_send call and may involve Codex app-server/runtime progress handling.

Expected behavior

• sessions_send timeout should cleanly fail the caller.
• If the target run is still active after the caller times out, it should either continue independently or be cancelled/marked failed, but it should not leave the caller blocked on sessions_history.
• model_call should have a hard timeout or recovery path.
• Stalled-session diagnostics should be able to abort/recover stuck runs, not only warn.
• One stuck inter-session delegation should not stall unrelated sessions.

Actual behavior

• sessions_send timed out.
• The requester later remained stuck in sessions_history.
• The target remained stuck in model_call after a completed tool result.
• Other sessions also stopped making progress.
• Recovery required gateway/container restart.

Mitigation applied locally

As a temporary workaround:

• disabled gateway-level sessions_send
• reduced default run timeout from 86400s to 900s
• reduced default agent concurrency from 3 to 2
• avoided cross-agent delegation and handled lookups in the current session directly

Requested fixes

1. Add/enforce a hard timeout and cancellation path for Codex model_call.
2. Ensure sessions_send timeout cancels or detaches the target safely and releases the caller.
3. Avoid synchronous caller blocking on target sessions_history after delegation timeout.
4. Add recovery/abort behavior to stalled-session detector.
5. Ensure a stalled run cannot block unrelated sessions in the app-server/runtime dispatcher.