OpenClaw Session Deadlock Fix: toolCall With No toolResult

What Causes the toolCall With No toolResult Deadlock?

When OpenClaw's AI model decides to use a tool (like searching the web, reading a file, or calling an API), it issues a toolCall message. OpenClaw receives this, executes the tool, and sends back a toolResult message. The model then uses that result to continue its response.

The deadlock occurs when the toolResult never makes it back to the model. The conversation enters a state where:

• The model is waiting for the tool result before it can continue
• OpenClaw either never executed the tool, or executed it but failed to record the result
• The session is stuck in an unrecoverable state

Common causes of the missing toolResult:

• Network timeout during tool execution: The tool made an HTTP request that timed out, and the error wasn't properly caught. The tool process exited without returning a result.
• Skill process crash: The skill being called threw an unhandled exception and crashed. OpenClaw logged the error but didn't send a failure result back to the model.
• Memory pressure: On low-memory systems, the skill process might get OOM-killed mid-execution. The result is never generated.
• Corrupted session file: A power loss, disk full condition, or Docker crash during session write can corrupt the session state, leaving a toolCall recorded but no toolResult.
• Race condition in concurrent tool calls: When the model issues multiple tool calls simultaneously, a race condition in older OpenClaw versions could cause one result to be dropped.

The result is always the same: the session is frozen. No new messages are processed for that conversation. Other conversations may continue to work normally, since deadlocks are session-specific.

How Do You Detect a Session Deadlock?

The symptoms of a session deadlock are distinct from other OpenClaw issues:

• Agent stops responding to messages in one conversation but may still work in others
• No errors in the main logs — the agent isn't crashing, it's just stuck
• CPU usage drops to near zero for the OpenClaw process (it's idle, not processing)
• The last log entry references a tool call with no corresponding result

To confirm a deadlock, check the logs:

# Check the last 100 lines of OpenClaw logs
docker compose logs --tail 100 openclaw

# Look for toolCall without a matching toolResult
# You'll see something like:
# [session:abc123] toolCall: web_search {"query": "..."}
# ... and then nothing after that for the session

You can also check the session files directly:

# List session files sorted by modification time
ls -lt ./data/sessions/

# The deadlocked session will be the one that hasn't been
# modified since the deadlock started

Why Doesn't a Docker Restart Fix It?

This is the most common mistake operators make. They notice the agent is stuck, restart the Docker container, and expect it to recover. It doesn't.

OpenClaw persists session state to disk. When the container restarts, it reads the session files and restores the conversation state — including the broken state where a toolCall has no toolResult. The model sees the pending tool call, waits for the result, and the deadlock resumes.

A restart is necessary but not sufficient. You need to clear the corrupted session state before restarting.

How Do You Fix the Deadlock?

Follow this procedure to resolve a session deadlock:

Step 1: Identify the affected session

# Check logs to find the session ID
docker compose logs --tail 200 openclaw | grep "toolCall"
# Note the session ID (e.g., session:abc123)

Step 2: Stop OpenClaw

docker compose down

Step 3: Remove the affected session file

# Remove just the affected session
rm ./data/sessions/abc123.json

# Or if you can't identify the specific session,
# remove all sessions (conversations will restart fresh):
rm -rf ./data/sessions/*

Step 4: Restart OpenClaw

docker compose up -d

Step 5: Verify recovery

# Send a test message to the affected conversation
# Check logs to confirm processing
docker compose logs -f openclaw

The affected conversation will lose its history (since you deleted the session), but the agent will be responsive again. All other conversations are unaffected if you only deleted the specific session file.

How Do You Prevent Session Deadlocks?

Prevention is better than cure. Here are the configurations and practices that minimize deadlock risk:

1. Set tool call timeouts

Add a timeout to your environment configuration so tool calls that hang are automatically cancelled:

# In your .env file
OPENCLAW_TOOL_TIMEOUT=30000  # 30 seconds
OPENCLAW_TOOL_RETRY=2        # Retry failed tools twice

With a timeout set, a hanging tool call will be cancelled after 30 seconds and a failure result will be sent to the model. The model can then decide what to do (retry, skip, or inform the user).

2. Enable automatic session recovery

# In your .env file
OPENCLAW_SESSION_RECOVERY=true
OPENCLAW_SESSION_MAX_PENDING_TOOLS=3

When session recovery is enabled, OpenClaw checks for pending tool calls on startup and automatically sends failure results for any that have been pending longer than the timeout. This prevents deadlocks from surviving a restart.

3. Test skills before deploying to production

Most deadlocks are caused by unreliable skills — skills that make HTTP requests without proper timeout handling, or skills that can crash on unexpected input. Test every skill on a staging instance before installing it on production.

4. Monitor session health

Set up a monitoring script that checks for stale sessions:

#!/bin/bash
# Alert if any session file hasn't been updated in 10 minutes
# but the agent is supposed to be active
find ./data/sessions/ -name "*.json" -mmin +10 -exec echo "Stale session: {}" \;

5. Keep OpenClaw updated

Recent OpenClaw versions (3.22+) include improved deadlock detection and session recovery. The race condition that affected concurrent tool calls was fixed in 3.21. Make sure you're running the latest stable version.

6. Use managed hosting

Remote OpenClaw managed deployments include automated session health monitoring and automatic recovery. If a deadlock is detected, the system clears the affected session and restarts the conversation — typically before the user even notices.