openclaw - ✅(Solved) Fix [Bug]: Severe slowdown, startup delay, and near-unusable responsiveness after upgrading from 2026.4.2 to 2026.4.26 on Codex setup [1 pull requests, 1 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
openclaw/openclaw#73298Fetched 2026-04-29 06:21:19
View on GitHub
Comments
0
Participants
1
Timeline
2
Reactions
1
Author
Participants
Timeline (top)
cross-referenced ×2

After upgrading this Debian host from OpenClaw 2026.4.2 to 2026.4.26 in a Codex-based setup, startup became much slower and the system became laggy / nearly unusable; rolling back to 2026.4.2 restored normal behavior.

Error Message

openclaw status

  • Gateway: app 2026.4.2 linux 6.12.63+deb13-amd64
  • Update available: npm update 2026.4.26

Representative logs:

  • Config was last written by a newer OpenClaw (2026.4.26); current version is 2026.4.2.
  • startup model warmup failed for openai-codex/gpt-5.5: Error: Unknown model: openai-codex/gpt-5.5
  • Model "openai-codex/gpt-5.5" not found. Fell back to "openrouter/openai/gpt-4o-mini".
  • Token refresh failed: 401
  • code": "refresh_token_reused"
  • gateway timeout after 30000ms
  • handshake timeout
  • stuck session

Root Cause

I cannot prove from the available evidence whether the root cause is:

  • a general 2026.4.26 regression,
  • a Codex-specific regression/path interaction,
  • config migration incompatibility,
  • or a combination of version/config/model-auth interactions.

Fix Action

Fix / Workaround

Steps to reproduce

  1. Start from a working OpenClaw 2026.4.2 installation on Debian using a Codex-based setup.
  2. Upgrade to OpenClaw 2026.4.26.
  3. Use the system normally after upgrade and observe startup time and interactive responsiveness.
  4. Observe severe slowness / lag / near-unusable behavior compared with 2026.4.2.
  5. Roll back to 2026.4.2 and observe that normal behavior returns.

Additional information

Last known good version: 2026.4.2 First known bad version: 2026.4.26 Observed workaround: roll back to 2026.4.2

PR fix notes

PR #73420: fix(gateway): avoid blocking channels on model prewarm

Description (problem / solution / changelog)

Summary

  • schedule primary model prewarm in the background instead of awaiting it before channel startup
  • keep the existing bounded prewarm timeout and startup trace span
  • add coverage that model prewarm scheduling does not wait for completion

Why

On my VPS, startup tracing showed Slack was not the slow part. The gateway logged ready, then spent 134s in sidecars.channels before Slack provider startup because primary model prewarm was still ahead of startChannels().

Current main already scopes and bounds that prewarm to 5s, which is a good improvement. This PR takes the next step and makes channel startup independent from prewarm latency.

Expected behavior: chat channels can come online promptly, while model prewarm still runs as best-effort startup work.

Related work

  • #60027 adds an opt-in env escape hatch to skip startup model warmup. This PR is different: it keeps warmup enabled by default but stops it from blocking channels.
  • #71203 refreshes configured agent models.json caches during startup. That is a separate cache correctness problem and should still be reviewable on its own.
  • #73276, #73353, #73411, and #72846 describe the same broad startup stall class that recent main fixes reduced. This PR closes the remaining ordering gap where channel startup still waits for model prewarm.
  • #73298 is still open as a broader slowdown report. This PR may help if its stall includes the same prewarm-before-channel ordering.

Tests

  • pnpm exec oxfmt --check src/gateway/server-startup-post-attach.ts src/gateway/server-startup-post-attach.test.ts CHANGELOG.md
  • pnpm exec vitest run --config test/vitest/vitest.gateway.config.ts src/gateway/server-startup-post-attach.test.ts src/gateway/server-startup.test.ts
  • pnpm check:test-types

Real-world validation

Before the local production mitigation, startup trace on my OpenClaw VPS showed sidecars.channels at 134006ms and Slack socket connected around 189s after gateway ready. After skipping blocking prewarm locally, sidecars.channels dropped to 571.8ms and Slack connected about 3.8s after gateway ready.

AI-assisted: yes. I reviewed the code and tests before opening this PR.

Changed files

  • CHANGELOG.md (modified, +1/-0)
  • src/gateway/server-startup-post-attach.test.ts (modified, +44/-1)
  • src/gateway/server-startup-post-attach.ts (modified, +28/-7)

Code Example

openclaw status
- Gateway: app 2026.4.2 linux 6.12.63+deb13-amd64
- Update available: npm update 2026.4.26

Representative logs:
- Config was last written by a newer OpenClaw (2026.4.26); current version is 2026.4.2.
- startup model warmup failed for openai-codex/gpt-5.5: Error: Unknown model: openai-codex/gpt-5.5
- Model "openai-codex/gpt-5.5" not found. Fell back to "openrouter/openai/gpt-4o-mini".
- Token refresh failed: 401
- code": "refresh_token_reused"
- gateway timeout after 30000ms
- handshake timeout
- stuck session
RAW_BUFFERClick to expand / collapse

[Bug]: Severe slowdown, startup delay, and near-unusable responsiveness after upgrading from 2026.4.2 to 2026.4.26 on Codex setup

Bug type

Regression (worked before, now fails)

Beta release blocker

No

Summary

After upgrading this Debian host from OpenClaw 2026.4.2 to 2026.4.26 in a Codex-based setup, startup became much slower and the system became laggy / nearly unusable; rolling back to 2026.4.2 restored normal behavior.

Steps to reproduce

  1. Start from a working OpenClaw 2026.4.2 installation on Debian using a Codex-based setup.
  2. Upgrade to OpenClaw 2026.4.26.
  3. Use the system normally after upgrade and observe startup time and interactive responsiveness.
  4. Observe severe slowness / lag / near-unusable behavior compared with 2026.4.2.
  5. Roll back to 2026.4.2 and observe that normal behavior returns.

Expected behavior

On the same host and workflow, OpenClaw should remain reasonably responsive after upgrade, and startup time should stay close enough to the last known good version that normal use is still practical. In 2026.4.2 on this host, behavior was normal.

Actual behavior

After upgrading to 2026.4.26, startup became slow and the system became laggy / slow enough to be described as nearly unusable. After rolling back to 2026.4.2, normal behavior returned.

Observed related evidence collected during follow-up inspection:

  • openclaw status on the affected environment showed the current app back on 2026.4.2, with Update available · npm update 2026.4.26.
  • Logs contained repeated warnings that the config had last been written by a newer OpenClaw version: Config was last written by a newer OpenClaw (2026.4.26); current version is 2026.4.2.
  • Logs during the affected period included Codex model resolution / fallback issues such as:
    • startup model warmup failed for openai-codex/gpt-5.5: Error: Unknown model: openai-codex/gpt-5.5
    • Model "openai-codex/gpt-5.5" not found. Fell back to "openrouter/openai/gpt-4o-mini".
  • Logs also included repeated Codex auth refresh errors:
    • Token refresh failed: 401
    • code": "refresh_token_reused"
  • Logs also showed timeouts / stuck behavior during the affected window, including:
    • gateway timeout after 30000ms
    • handshake timeout
    • stuck session

OpenClaw version

Last known good: 2026.4.2 First known bad: 2026.4.26

Operating system

Debian Linux 6.12.63+deb13-amd64 (x86_64)

Install method

npm global

Model

openai-codex/gpt-5.4 in the currently restored config; affected upgrade investigation also captured attempted resolution of openai-codex/gpt-5.5 during the bad state.

Provider / routing chain

openclaw -> openai-codex (with observed fallback to openrouter/openai/gpt-4o-mini during the bad state)

Additional provider/model setup details

This host is used with a Codex-based setup. During follow-up inspection after rollback, the restored config showed agents.defaults.model.primary = openai-codex/gpt-5.4 and plugins brave, deepseek, memory-lancedb, nextcloud-talk, openai, openrouter.

During the affected period, logs showed attempted startup warmup for openai-codex/gpt-5.5, which then failed as unknown and fell back to openrouter/openai/gpt-4o-mini. The same logs also showed repeated Codex refresh-token failures (refresh_token_reused).

I cannot prove from the available evidence whether the root cause is:

  • a general 2026.4.26 regression,
  • a Codex-specific regression/path interaction,
  • config migration incompatibility,
  • or a combination of version/config/model-auth interactions.

Logs, screenshots, and evidence

openclaw status
- Gateway: app 2026.4.2 linux 6.12.63+deb13-amd64
- Update available: npm update 2026.4.26

Representative logs:
- Config was last written by a newer OpenClaw (2026.4.26); current version is 2026.4.2.
- startup model warmup failed for openai-codex/gpt-5.5: Error: Unknown model: openai-codex/gpt-5.5
- Model "openai-codex/gpt-5.5" not found. Fell back to "openrouter/openai/gpt-4o-mini".
- Token refresh failed: 401
- code": "refresh_token_reused"
- gateway timeout after 30000ms
- handshake timeout
- stuck session

Impact and severity

Affected: this Debian host running a Codex-based OpenClaw setup Severity: High (normal use became nearly impractical after upgrade) Frequency: Observed after upgrading to 2026.4.26; rollback to 2026.4.2 restored normal behavior Consequence: Severe slowdown, slow startup, and degraded interactive usability until rollback

Additional information

Last known good version: 2026.4.2 First known bad version: 2026.4.26 Observed workaround: roll back to 2026.4.2

Release-note review did not show an explicit known regression entry for this exact symptom. Based on official release-note review plus local evidence, the most plausible areas were Codex runtime/model-path changes, config migration/version skew, diagnostics/runtime overhead, or related startup-path interactions; however, that part is inference rather than directly proven by the attached evidence.

extent analysis

TL;DR

The most likely fix or workaround for the severe slowdown and responsiveness issues after upgrading from OpenClaw 2026.4.2 to 2026.4.26 is to roll back to version 2026.4.2, as this has been observed to restore normal behavior.

Guidance

  • Review the Codex model configuration and ensure that the primary model is set to a compatible version, such as openai-codex/gpt-5.4, which was used in the restored config.
  • Investigate the Codex auth refresh errors, such as Token refresh failed: 401 and code": "refresh_token_reused", and verify that the authentication tokens are properly configured and not being reused.
  • Check the OpenClaw logs for any other errors or warnings that may indicate a configuration or compatibility issue, such as the Config was last written by a newer OpenClaw (2026.4.26); current version is 2026.4.2 warning.
  • Consider testing the upgrade again with a clean configuration and minimal plugins to isolate the issue and determine if it is specific to the Codex setup or a more general regression.

Example

No specific code example is provided, as the issue appears to be related to configuration and compatibility rather than a specific code error.

Notes

The root cause of the issue is unclear, and it may be related to a general regression in OpenClaw 2026.4.26, a Codex-specific regression, or a configuration migration incompatibility. Further investigation and testing are needed to determine the exact cause and develop a more targeted fix.

Recommendation

Apply the workaround of rolling back to OpenClaw 2026.4.2, as this has been observed to restore normal behavior, until a more permanent fix can be developed and tested.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

FAQ

Expected behavior

On the same host and workflow, OpenClaw should remain reasonably responsive after upgrade, and startup time should stay close enough to the last known good version that normal use is still practical. In 2026.4.2 on this host, behavior was normal.

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

openclaw - ✅(Solved) Fix [Bug]: Severe slowdown, startup delay, and near-unusable responsiveness after upgrading from 2026.4.2 to 2026.4.26 on Codex setup [1 pull requests, 1 participants]