Bug type
Behavior bug (incorrect output/state without crash)
Beta release blocker
No
Summary
The Control UI session sidebar can wait close to a minute for Claude and Codex catalogs when several paired macOS nodes are connected.
Steps to reproduce
- Run OpenClaw 2026.7.2-beta.2 with Claude and Codex session catalogs enabled.
- Connect four macOS nodes that advertise the native Claude and Codex catalog commands.
- Open the Control UI and wait for the external session sections.
- Time one complete session catalog request, then time provider-specific and per-node requests.
Expected behavior
Available Claude and Codex sessions should appear promptly. Catalog repair or a slow node should not keep the entire sidebar empty for tens of seconds.
Actual behavior
One observed four-node catalog request took 69.9 seconds end to end. Provider-only requests took 17.4 seconds for Claude and 49.0 seconds for Codex. The Gateway waits for every provider and host before returning any catalog.
OpenClaw version
2026.7.2-beta.2
Operating system
macOS 26.5 through macOS 27.0
Install method
Signed macOS development app plus source-checkout Gateway
Model
N/A (session catalog metadata only)
Provider / routing chain
Control UI -> Gateway -> bundled session catalog plugins -> paired macOS nodes -> Claude session files or Codex App Server
Logs
combined catalog: 69.898s
Claude catalog: 17.378s
Codex catalog: 49.009s
Direct Codex thread/list on one affected Mac after metadata repair:
scan-and-repair: 2697ms, 1283ms
state-DB-only: 215ms, 218ms
No session titles, IDs, transcript contents, or local paths were captured in the benchmark output.
Screenshots, recordings, and evidence
A Time Profiler capture of the signed macOS node showed the OpenClaw app blocked while a short-lived Codex App Server child performed the catalog request. Source inspection confirms that every node list request launches a new App Server and explicitly requests the scan-and-repair path.
Impact and severity
Affected: users with native Claude or Codex sessions on several paired Macs.
Severity: annoying and workflow-blocking for session navigation, without data loss.
Frequency: reproduced on the initial four-node load; host cost varies with local catalog size and cache state.
Consequence: the external session sections remain empty while users wait, even when some hosts have already finished.
Additional information
The state-DB-only Codex path is substantially faster, but using it alone can omit older rollout metadata that has not yet been repaired into the state database. A fix should preserve eventual metadata repair while removing repair scans from the interactive request path. Claude catalog discovery also rescans unindexed JSONL prefixes on every list request, and its Gateway-local scan currently finishes before node fan-out begins.
Bug type
Behavior bug (incorrect output/state without crash)
Beta release blocker
No
Summary
The Control UI session sidebar can wait close to a minute for Claude and Codex catalogs when several paired macOS nodes are connected.
Steps to reproduce
Expected behavior
Available Claude and Codex sessions should appear promptly. Catalog repair or a slow node should not keep the entire sidebar empty for tens of seconds.
Actual behavior
One observed four-node catalog request took 69.9 seconds end to end. Provider-only requests took 17.4 seconds for Claude and 49.0 seconds for Codex. The Gateway waits for every provider and host before returning any catalog.
OpenClaw version
2026.7.2-beta.2
Operating system
macOS 26.5 through macOS 27.0
Install method
Signed macOS development app plus source-checkout Gateway
Model
N/A (session catalog metadata only)
Provider / routing chain
Control UI -> Gateway -> bundled session catalog plugins -> paired macOS nodes -> Claude session files or Codex App Server
Logs
No session titles, IDs, transcript contents, or local paths were captured in the benchmark output.
Screenshots, recordings, and evidence
A Time Profiler capture of the signed macOS node showed the OpenClaw app blocked while a short-lived Codex App Server child performed the catalog request. Source inspection confirms that every node list request launches a new App Server and explicitly requests the scan-and-repair path.
Impact and severity
Affected: users with native Claude or Codex sessions on several paired Macs.
Severity: annoying and workflow-blocking for session navigation, without data loss.
Frequency: reproduced on the initial four-node load; host cost varies with local catalog size and cache state.
Consequence: the external session sections remain empty while users wait, even when some hosts have already finished.
Additional information
The state-DB-only Codex path is substantially faster, but using it alone can omit older rollout metadata that has not yet been repaired into the state database. A fix should preserve eventual metadata repair while removing repair scans from the interactive request path. Claude catalog discovery also rescans unindexed JSONL prefixes on every list request, and its Gateway-local scan currently finishes before node fan-out begins.