openclaw - 💡(How to fix) Fix [Bug]: `sessions.patch` silently deletes user-set label when store entry exists but has no sessionId yet

Bug type

Behavior bug (incorrect output/state without crash)

Beta release blocker

No

Summary

Setting a session label via sessions.patch silently drops the label if the store entry already exists but does not yet have a sessionId. This makes it impossible to set a label on a session from the Control UI before the session has processed its first message.

Steps to reproduce

1. Start OpenClaw 2026.5.18 (or 2026.5.19).
2. A session store entry exists for a session key (e.g. agent:main:main) but has not yet been assigned a sessionId (no messages processed).
3. From Control UI sessions panel or via RPC, call sessions.patch on that session key with { label: "My Label" }.
4. Verify the store via cat ~/.openclaw/agents/main/sessions/sessions.json — the label field is absent.

Expected behavior

If the caller explicitly sets label in the patch, that value should be persisted regardless of whether sessionId has been assigned yet. The cleanup of label/displayName should only apply when the current patch does not include those fields (i.e. preserve user intent from the current call).

Actual behavior

The label is silently deleted from the store. The sessions.patch handler at line ~169 correctly sets next.label = parsed.label, but earlier at lines ~72–74 the code unconditionally wipes it:

// src/gateway/sessions-patch.ts
if (existing && !existing.sessionId) {
    delete next.label;
    delete next.displayName;
}

This cleanup runs before the label handler, so any label set in the current patch is always discarded when existing.sessionId is falsy.

Confirmed by inspecting sessions.json on disk — label is null after a successful patch call.

OpenClaw version

< 2026.5.19

Operating system

Windows 11 + WSL2 Ubuntu (Linux 6.6.87.2-microsoft-standard-WSL2)

Install method

pnpm global

Model

qwen

Provider / routing chain

Direct: openclaw → alibaba/qwen3.6-plus

Additional provider/model setup details

Default model configuration, no special routing or overrides.

Logs, screenshots, and evidence

Source code evidence in `dist/sessions-patch-BTF2zcyq.js` lines 72–74 and 159–169. On-disk store inspection shows `label: null` after patch:


key=agent:main:main, label=None, origin.label=None

Impact and severity

Affected: All users attempting to set session labels from Control UI on not-yet-initialized sessions. Severity: Blocks workflow — labels are silently lost with no error feedback. Frequency: Always (100% repro) when existing && !existing.sessionId. Consequence: Users cannot organize or rename sessions in the Control UI sessions panel; the label appears to save but disappears on next load.

Additional information

Suggested fix: gate the label/displayName cleanup on the absence of those fields in the current patch:

if (existing && !existing.sessionId && !("label" in patch)) {
    delete next.label;
}
if (existing && !existing.sessionId && !("displayName" in patch)) {
    delete next.displayName;
}

Or move the sessionId assignment (which already generates randomUUID() at line ~68) to run before the cleanup check, so the !existing.sessionId condition is no longer true by that point.

Last known good: unknown (suspected this behavior has existed since the cleanup guard was introduced). First known bad: observed in 2026.5.18.