Summary

After upgrading from 2026.4.12 to 2026.4.14, all existing conversations across multiple models/surfaces started failing with the generic UI error:

⚠️ Something went wrong while processing your request. Please try again, or use /new to start a fresh session.

This was not limited to Codex. It affected multiple conversation threads and multiple models. Rolling back to 2026.4.12 restored normal behavior.

From gateway logs, the most consistent failure pattern was repeated active-memory timeouts on the pre-reply path.

Environment

• OpenClaw 2026.4.12 -> upgraded to 2026.4.14 -> rolled back to 2026.4.12
• macOS ARM64
• Existing long-lived conversations / reused sessions
• Multiple agents/models in use, not only Codex
• Active Memory enabled
• Surfaces observed in logs: Feishu direct, Weixin direct
• User-facing symptom was broad: multiple existing chats failed after the upgrade, regardless of model

What happened

Immediately after upgrading to 2026.4.14, existing conversations began failing with the generic "Something went wrong" message.

This did not look like a single provider outage:

• not limited to Codex
• not limited to one agent
• not limited to one conversation
• rolling back fixed it

Gateway log evidence

Repeated pattern on 2026-04-14:

2026-04-14T05:48:42.617+08:00 [plugins] active-memory: agent=agent-qwen session=agent:agent-qwen:feishu:direct:... start timeoutMs=15000 queryChars=633
2026-04-14T05:48:57.667+08:00 [plugins] active-memory: agent=agent-qwen session=agent:agent-qwen:feishu:direct:... done status=timeout elapsedMs=15050 summaryChars=0

2026-04-14T05:57:43.915+08:00 [plugins] active-memory: agent=agent-qwen session=agent:agent-qwen:feishu:direct:... start timeoutMs=15000 queryChars=1262
2026-04-14T05:57:58.984+08:00 [plugins] active-memory: agent=agent-qwen session=agent:agent-qwen:feishu:direct:... done status=timeout elapsedMs=15070 summaryChars=0

2026-04-14T06:00:32.061+08:00 [plugins] active-memory: agent=agent-qwen session=agent:agent-qwen:feishu:direct:... start timeoutMs=15000 queryChars=1299
2026-04-14T06:00:47.127+08:00 [plugins] active-memory: agent=agent-qwen session=agent:agent-qwen:feishu:direct:... done status=timeout elapsedMs=15066 summaryChars=0

2026-04-14T15:54:23.342+08:00 [plugins] active-memory: agent=agent-qwen session=agent:agent-qwen:feishu:direct:... start timeoutMs=15000 queryChars=1254
2026-04-14T15:54:38.424+08:00 [plugins] active-memory: agent=agent-qwen session=agent:agent-qwen:feishu:direct:... done status=timeout elapsedMs=15083 summaryChars=0

2026-04-14T16:00:00.843+08:00 [plugins] active-memory: agent=agent-qwen session=agent:agent-qwen:feishu:direct:... done status=timeout elapsedMs=15066 summaryChars=0

2026-04-14T17:01:55.016+08:00 [plugins] active-memory: agent=agent-qwen session=agent:agent-qwen:feishu:direct:... done status=timeout elapsedMs=15054 summaryChars=0

2026-04-14T19:05:45.322+08:00 [plugins] active-memory: agent=agent-qwen session=agent:agent-qwen:openclaw-weixin:direct:... done status=timeout elapsedMs=15057 summaryChars=0

There were also some status=empty results, but the repeated 15s timeouts were the dominant pattern.

Why this seems important

This looks like Active Memory is blocking the reply-critical path and timing out often enough in 2026.4.14 to make existing conversations broadly fail with the generic UI error.

This seems related to the general class of Active Memory / pre-reply path instability already discussed in issues like #65309, but the symptom here is broader:

• upgrade to 2026.4.14
• multiple existing conversations fail
• multiple models affected
• generic front-end error shown to the user
• rollback to 2026.4.12 restores service

Expected behavior

If Active Memory exceeds budget or fails, the user conversation should continue in a fail-open / skipped-memory mode instead of collapsing into a generic conversation failure.

Actual behavior

After upgrade to 2026.4.14, multiple existing chats across models started failing with:

Something went wrong while processing your request. Please try again, or use /new to start a fresh session.

Workaround

Rolling back from 2026.4.14 to 2026.4.12 restored normal behavior.

Possible directions

• fail-open behavior when active-memory times out
• clearer logging / surfacing of pre-reply Active Memory timeout vs provider/model failure
• check whether 2026.4.14 changed the reply-critical path for Active Memory on reused sessions / existing conversations