openclaw - 💡(How to fix) Fix [Bug]: assistant turn can enter repeated terminated state immediately after a tool error instead of reporting the failure [1 comments, 1 participants]

Bug type

Behavior bug (incorrect output/state without crash)

Summary

In a main chat session on OpenClaw 2026.4.21 using openai-codex/gpt-5.4, a real tool failure occurred during an active turn, and instead of returning a normal assistant message explaining the failure, the run fell into repeated error=terminated assistant responses.

This was not a long-running overnight turn. It happened immediately after a concrete tool error during a normal interactive turn.

The proximate tool failure was an external CLI auth/permission error from a shell command invoked through exec.

After that tool result, the assistant did not send a normal reply saying the command failed or asking to retry with corrected auth/context. Instead, the session history showed repeated assistant entries with:

• stopReason: error
• errorMessage: terminated

This caused the user to see the turn as terminated instead of receiving the actual failure report.

Steps to reproduce

1. Use OpenClaw 2026.4.21 in a normal main agent session with model openai-codex/gpt-5.4.
2. Ask the assistant to do real work that uses tools.
3. Trigger a concrete tool error during the turn. In our case this was an exec shell command invoking an external CLI that returned an auth/permission failure.
4. Observe what happens after the tool result arrives.

Expected behavior

After a tool error, the assistant should still be able to produce a normal response for the user, for example:

• report the exact tool failure
• explain the likely cause
• ask for permission to retry or retry with corrected context if appropriate

At minimum, the run should fail once, clearly, instead of degrading into repeated terminated assistant responses.

Actual behavior

The tool error landed successfully in session history, but the subsequent assistant responses were repeatedly marked:

• stopReason: error
• errorMessage: terminated

The user saw the turn terminate instead of receiving the actual failure explanation.

OpenClaw version

2026.4.21

Operating system

Linux

Install method

npm global

Model

openai-codex/gpt-5.4

Provider / routing chain

OpenClaw -> OpenAI Codex

Additional provider/model setup details

Main session model was openai-codex/gpt-5.4.

Logs, screenshots, and evidence

Relevant session-history sequence:

1. User asked for real work in a normal interactive turn.
2. Assistant successfully called:
   • update_plan
   • one exec command that later failed with an auth/permission error
   • another local exec command that succeeded
3. The failing exec tool result returned a concrete permission/auth error.
4. After that, the assistant generated multiple entries with errorMessage: terminated instead of a normal text reply.

Representative failing tool result shape:

<external CLI permission/auth error>
(Command exited with code 1)

Observed repeated assistant error state immediately after:

stopReason: error
errorMessage: terminated

Impact and severity

Medium to high.

This breaks trust in the runtime because a normal tool failure gets swallowed by repeated termination behavior. The user does not get the real error report, and it looks like the assistant simply died mid-turn.

Additional information

There is an existing issue about interrupted streaming tool calls and retry loops:

• #53109 Better handling for interrupted streaming tool calls to avoid silent failure and retry loops

This report may be related, but this repro is narrower and clearer:

• a concrete tool error is already present in session history
• then the assistant repeatedly terminates instead of reporting that tool failure back to the user

So this may be the same family, but if so it would be helpful to track that this also happens in the simpler "tool error arrived normally, post-tool assistant reply terminated" case.