Summary

System prompt instructs agents to use sessionKey="current" to refer to the current session in tools like session_status, sessions_history, and sessions_send. The upper-level tool wrappers handle this alias correctly and return successful results, but the underlying gateway ws action sessions.resolve does not accept the "current" literal — it returns INVALID_REQUEST: No session found: current.

The error is logged once per call, then the wrapper falls back to the correct path and the user-visible result succeeds. Net effect: every legitimate use of the recommended alias generates one ✗ log line.

Version

• OpenClaw 2026.5.5 (b1abf9d)
• Reproducible on 2026.5.4 as well (logs predate the upgrade)

Reproduction

From any agent session, call any tool that supports sessionKey="current", for example:

• session_status(sessionKey="current")
• sessions_history(sessionKey="current", limit=5)

Observe gateway journalctl logs:

[ws] ⇄ res ✗ sessions.resolve 2ms errorCode=INVALID_REQUEST errorMessage=No session found: current conn=<connId> id=<reqId>
[ws] ⇄ res ✓ sessions.list 97ms conn=<connId> id=<reqId>

The tool returns a successful result to the agent (status card / history payload), so functionality is unaffected from the agent's perspective.

Expected behavior

sessions.resolve should accept "current" as a special alias and resolve it to the calling client's current session key, consistent with the system prompt and the wrapper behavior.

Alternatively: the wrapper layer should resolve "current" to the concrete session key before invoking sessions.resolve, so the ws action never sees the literal string.

Actual behavior

sessions.resolve rejects "current" with INVALID_REQUEST. The wrapper layer falls back, but the failed roundtrip is recorded in logs.

Impact

• Functional: none (results succeed)
• Performance: negligible (1–2ms wasted ws roundtrip per call)
• Operational: log noise — every sessionKey="current" call records one ✗ line, making real failures harder to spot in journalctl -u openclaw-gateway

Suggested fix

Add a "current" alias resolver inside the sessions.resolve ws action handler, using the calling connection's tracked session as the resolved key. This mirrors what the wrappers already do, so they can stop the local fallback once the gateway is consistent.

Workaround

None practical — the system prompt explicitly forbids using UI/client labels (e.g., "openclaw-tui") as session keys, and instructs agents to use "current". Hard-coding the actual session key string would violate the prompt and is brittle across thread/reset boundaries.

Notes

• Found while debugging an unrelated thread routing issue (each thread child message creating its own session — fixed by the 5.4 → 5.5 upgrade).
• This issue was visible in journalctl logs both before and after the routing fix, indicating it is independent of the routing fix.

Sample log lines

May 06 10:24:04 ip-10-5-1-109 node[79346]: 2026-05-06T10:24:04.032+00:00 [ws] ⇄ res ✗ sessions.resolve 2ms errorCode=INVALID_REQUEST errorMessage=No session found: current conn=3f2d933c…ad74 id=c86fb4e4…58b0
May 06 10:24:04 ip-10-5-1-109 node[79346]: 2026-05-06T10:24:04.039+00:00 [ws] ⇄ res ✗ sessions.resolve 1ms errorCode=INVALID_REQUEST errorMessage=No session found: current conn=74997a11…4831 id=df0034fd…d450