openclaw - 💡(How to fix) Fix Gateway silently drops agent spawns when log file hits maxFileBytes cap [1 participants]

When the gateway log file reaches the maxFileBytes cap (default 512MB at /tmp/openclaw/<date>.log), the gateway emits [openclaw] log file size cap reached; suppressing writes and continues accepting WebSocket RPC calls (chat.send). However, agent sessions dispatched via chat.send during this state fail to actually spawn — the gateway returns a successful response (no error) but the agent process never starts. The caller has no way to detect this failure.

• Option A: Gateway should return an error from chat.send when it cannot guarantee agent spawn due to log suppression, so callers can retry or fail gracefully

TL;DR

Truncating the log file and restarting the gateway is a viable workaround to resolve the issue of agent sessions failing to spawn when the log file size cap is reached.

Guidance

• To verify the issue, check the gateway logs for the message [openclaw] log file size cap reached; suppressing writes and confirm that agent sessions are not being spawned despite successful chat.send responses.
• Consider implementing log rotation to prevent the log file from reaching the size cap, such as renaming the capped file to .1 and starting a fresh one.
• Review the gateway configuration to determine if the maxFileBytes setting can be adjusted to a larger value to reduce the frequency of log file size caps.
• To mitigate the issue, implement error handling on the caller side to detect and retry failed agent dispatches, in case the gateway returns a successful response but the agent session fails to spawn.

Example

# Truncate the log file and restart the gateway
> /tmp/openclaw/openclaw-<date>.log
kill -TERM <gateway-pid>
openclaw gateway start

Notes

The root cause of the issue appears to be the log file size cap being reached, causing the gateway to suppress log writes and fail to spawn agent sessions. The workaround provided is effective but may not be a long-term solution. Implementing log rotation or adjusting the maxFileBytes setting may be necessary to prevent the issue from recurring.

Recommendation

Apply the workaround of truncating the log file and restarting the gateway, as it provides a immediate solution to the issue. However, it is recommended to also investigate implementing log rotation or adjusting the maxFileBytes setting to prevent the issue from recurring in the future.