openclaw - 💡(How to fix) Fix CLI `--session-id <new-uuid>` silently remapped to existing agent:<id>:main session [1 comments, 2 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#71415Fetched 2026-04-26 05:13:05
View on GitHub
Comments
1
Participants
2
Timeline
2
Reactions
0
Participants
Timeline (top)
closed ×1commented ×1

openclaw agent --agent <id> --session-id <new-uuid> is silently ignored when an active agent:<id>:main session already exists in agents/<id>/sessions/sessions.json. The new UUID is accepted on the command line but the run is routed through the existing session, leaking stale conversation history into what the operator believes is a fresh run.

Error Message

  • Refuse with a clear error if the ID conflicts with an existing one, OR

Root Cause

Operators and tests that rely on fresh runs (regression test, new triage, cost-controlled probe) will silently get stale-context replies. The behaviour also makes it impossible to run two parallel independent runs against the same agent without first manually clearing agents/<id>/sessions/.

Fix Action

Workaround

Move agents/<id>/sessions/ aside before each run that requires isolation:

mv /data/.openclaw/agents/<id>/sessions /data/.openclaw/agents/<id>/sessions.bak.$(date -u +%Y%m%dT%H%M%SZ)

The runtime then creates a fresh sessions.json + jsonl on next invocation.

Code Example

openclaw agent --agent db --session-id $(uuidgen) --json -m "ping, reply in 5 words"

---

mv /data/.openclaw/agents/<id>/sessions /data/.openclaw/agents/<id>/sessions.bak.$(date -u +%Y%m%dT%H%M%SZ)
RAW_BUFFERClick to expand / collapse

Summary

openclaw agent --agent <id> --session-id <new-uuid> is silently ignored when an active agent:<id>:main session already exists in agents/<id>/sessions/sessions.json. The new UUID is accepted on the command line but the run is routed through the existing session, leaking stale conversation history into what the operator believes is a fresh run.

Reproduction

  1. Run an agent and let it create an agent:<id>:main session.
  2. On the next run, pass --session-id $(uuidgen):
    openclaw agent --agent db --session-id $(uuidgen) --json -m "ping, reply in 5 words"
  3. Inspect the resulting meta.agentMeta.sessionId in the JSON output and the sessionKey in systemPromptReport.

Observed behaviour

The run report shows a sessionId matching the previously existing agent:db:main session (not the UUID I passed). The promptTokens count includes the entire prior conversation (e.g. 16,408 input tokens for a "ping" message in our reproduction).

Expected behaviour

One of:

  • Honour the --session-id flag and create a brand-new session record under that ID, OR
  • Refuse with a clear error if the ID conflicts with an existing one, OR
  • Document that --session-id only acts as a retrieval knob (must already exist) and provide a separate --new-session flag for fresh-run intent.

Why this matters

Operators and tests that rely on fresh runs (regression test, new triage, cost-controlled probe) will silently get stale-context replies. The behaviour also makes it impossible to run two parallel independent runs against the same agent without first manually clearing agents/<id>/sessions/.

Workaround

Move agents/<id>/sessions/ aside before each run that requires isolation:

mv /data/.openclaw/agents/<id>/sessions /data/.openclaw/agents/<id>/sessions.bak.$(date -u +%Y%m%dT%H%M%SZ)

The runtime then creates a fresh sessions.json + jsonl on next invocation.

Environment

OpenClaw 2026.4.12 (1c0672b).

extent analysis

TL;DR

The issue can be worked around by moving the existing sessions directory aside before each run that requires isolation, allowing the runtime to create a fresh session.

Guidance

  • Verify that the --session-id flag is being passed correctly and that the UUID generated is unique.
  • Check the agents/<id>/sessions/sessions.json file to ensure that a new session is not being created when the --session-id flag is used.
  • Consider using the provided workaround to move the existing sessions directory aside before each run that requires isolation.
  • Review the OpenClaw documentation to see if there are any plans to address this issue in a future release or if there are any other workarounds available.

Example

mv /data/.openclaw/agents/<id>/sessions /data/.openclaw/agents/<id>/sessions.bak.$(date -u +%Y%m%dT%H%M%SZ)
openclaw agent --agent <id> --session-id $(uuidgen) --json -m "ping, reply in 5 words"

Notes

This workaround may not be suitable for all use cases, especially those that require preserving existing session data. It is also worth noting that this issue may be specific to OpenClaw version 2026.4.12 (1c0672b).

Recommendation

Apply the workaround to move the existing sessions directory aside before each run that requires isolation, as this allows for fresh runs without modifying the existing session data.

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…

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 - 💡(How to fix) Fix CLI `--session-id <new-uuid>` silently remapped to existing agent:<id>:main session [1 comments, 2 participants]