Summary

Session trajectory-path files (.trajectory-path.json) are never pruned from the agent sessions directory. As the gateway accumulates sessions over days of operation, directory scan–dependent operations — particularly node.list and session-write-lock — degrade proportionally. At ~950 files we observe node.list calls taking 20–35 seconds, causing UI stalls, missed Slack WebSocket pong frames, and cron scheduling delays.

This is distinct from #72826 (synchronous sessionStore maintenance / OOM), which is closed and fixed in 2026.4.25. That fix addresses sessions.json write contention; it does not address trajectory-path file accumulation or directory-scan-based latency.

Environment

• OpenClaw version: 2026.4.24 (v2026.4.25 with #72826 fix not yet installed)
• Host: 2 vCPU, 8 GB RAM, Ubuntu 24.04
• Agent: main (primary agent handling WhatsApp, Slack, and ~50 scheduled crons)
• Operational age: ~7 days continuous operation

Observed data

sessions directory

$ ls ~/.openclaw/agents/main/sessions/*.trajectory-path.json | wc -l
949

$ du -sh ~/.openclaw/agents/main/sessions/
29M    ~/.openclaw/agents/main/sessions/

$ ls -lh ~/.openclaw/agents/main/sessions/sessions.json
-rw------- 1 root root 759K  sessions.json     <- capped at 25 entries via maxEntries

Despite session.maintenance.maxEntries=25 keeping sessions.json at 759 KB, the directory holds 949 .trajectory-path.json pointer files and 16 active .trajectory.jsonl files (largest: 2.3 MB). Every session ever created leaves a permanent .trajectory-path.json entry that is never removed.

node.list latency (gateway journal, 2026-04-27)

[ws] res node.list 34632ms
[ws] res node.list 20231ms

When the directory had far fewer files (early in the week): node.list was sub-second. The web UI polls node.list on every page load; at 20-35s, the control panel becomes unusable during stalls.

session-write-lock contention (same day)

[session-write-lock] releasing lock held for 73416ms (max=15000ms):
  ~/.openclaw/agents/main/sessions/sessions.json.lock

Lock held for 73 seconds vs. the documented 15-second max.

Previous day (2026-04-26, ~400 fewer files)

[ws] res node.list 43422ms     <- full event-loop stall

Latency tracks file count, not gateway uptime.

Root cause hypothesis

node.list (and related operations that walk the session store) appears to stat or read the sessions directory proportionally to the number of files present. .trajectory-path.json files are created for every session but never removed, even when the session is pruned from sessions.json by the maxEntries maintenance pass.

The result: sessions.json stays bounded by maxEntries, but the directory grows without bound. Orphaned trajectory-path files (and their .jsonl counterparts) continue to inflate directory-scan costs indefinitely.

Suggested fixes

1. Prune orphaned .trajectory-path.json files when a session is evicted from sessions.json by the maintenance pass. The corresponding .jsonl and any .jsonl.reset.* rotations should be removed at the same time.

2. Include trajectory-path cleanup in openclaw sessions cleanup --enforce (added in #72826). Currently enforces maxEntries on sessions.json; it should also sweep the directory and remove .trajectory-path.json / .trajectory.jsonl files whose session ID is no longer present in sessions.json.

3. Make node.list independent of trajectory-path file count. If the operation does a readdir to enumerate active sessions, it should only consult sessions.json (bounded by maxEntries) rather than the on-disk directory. The on-disk count and the in-memory store count are already intentionally divergent once eviction begins.

Workaround (applied locally)

None applied — manually deleting trajectory files is risky without knowing which are actively referenced. Running a daily gateway restart as a partial mitigation (clears in-memory pressure, does not reduce on-disk file count).

Note: Upgrading to 2026.4.25 (which fixes #72826) is expected to reduce session-write-lock hold time via async maintenance, but will not reduce node.list latency since the trajectory-path file count is unaffected.

Impact

• UI lagginess: Control panel becomes unresponsive during 20-35s node.list stalls
• Slack socket reconnections: 34-second event-loop stalls cause @slack/socket-mode's 5s pong timeout to fire, producing ~50-90 socket reconnects per 15-minute window
• Cron scheduling jitter: Jobs fire late because the scheduler cannot acquire the event loop during a stall

Happy to share the directory listing or sessions.json (redacted) if useful.