openclaw - 💡(How to fix) Fix bug(cron): isolated runs reuse CLI session — cliSessionIds not cleared on forceNew [1 comments, 1 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#63288Fetched 2026-04-09 07:55:50
View on GitHub
Comments
1
Participants
1
Timeline
3
Reactions
0
Participants
Timeline (top)
closed ×1commented ×1cross-referenced ×1

Root Cause

The comment at run.ts says "Isolated cron runs must not carry prior turn context across executions" — but because cliSessionIds is preserved, getCliSessionId() returns the previous run's CLI session ID, and the CLI runtime resumes it via --resume.

Code Example

const sessionEntry: SessionEntry = {
    ...entry,           // ← preserves cliSessionIds from prior run
    sessionId,          // ← new OpenClaw session ID
    updatedAt: params.nowMs,
    systemSent,
    ...(isNewSession && {
      lastChannel: undefined,
      lastTo: undefined,
      lastAccountId: undefined,
      lastThreadId: undefined,
      deliveryContext: undefined,
      // cliSessionIds NOT cleared here
    }),
  };

---

...(isNewSession && {
    lastChannel: undefined,
    lastTo: undefined,
    lastAccountId: undefined,
    lastThreadId: undefined,
    deliveryContext: undefined,
    cliSessionIds: undefined,      // ← should be cleared
}),
RAW_BUFFERClick to expand / collapse

Problem

When sessionTarget: "isolated" cron jobs run, resolveCronSession is called with forceNew: true. This creates a new OpenClaw session ID, but the cliSessionIds map is preserved from the previous session entry via the ...entry spread.

File: src/cron/isolated-agent/session.ts

const sessionEntry: SessionEntry = {
    ...entry,           // ← preserves cliSessionIds from prior run
    sessionId,          // ← new OpenClaw session ID
    updatedAt: params.nowMs,
    systemSent,
    ...(isNewSession && {
      lastChannel: undefined,
      lastTo: undefined,
      lastAccountId: undefined,
      lastThreadId: undefined,
      deliveryContext: undefined,
      // cliSessionIds NOT cleared here
    }),
  };

The comment at run.ts says "Isolated cron runs must not carry prior turn context across executions" — but because cliSessionIds is preserved, getCliSessionId() returns the previous run's CLI session ID, and the CLI runtime resumes it via --resume.

Impact

  • Each isolated cron run accumulates turns in the same CLI session — conversation history grows indefinitely
  • The "isolated" guarantee is broken at the CLI layer: the agent sees all prior cron prompts and responses
  • Context window fills up over time for frequently running cron jobs

Expected behavior

When forceNew: true, cliSessionIds should be cleared so the CLI runtime starts a fresh session:

...(isNewSession && {
    lastChannel: undefined,
    lastTo: undefined,
    lastAccountId: undefined,
    lastThreadId: undefined,
    deliveryContext: undefined,
    cliSessionIds: undefined,      // ← should be cleared
}),

extent analysis

TL;DR

Clearing the cliSessionIds property when forceNew: true should resolve the issue of accumulated turns in isolated cron runs.

Guidance

  • The likely cause is the preservation of cliSessionIds from the previous session entry, which prevents the CLI runtime from starting a fresh session.
  • To verify the fix, check that getCliSessionId() returns a new CLI session ID for each isolated cron run, and that the conversation history does not grow indefinitely.
  • To mitigate the issue, ensure that cliSessionIds is cleared when isNewSession is true, as shown in the expected behavior code snippet.
  • Review the session.ts file to confirm that the cliSessionIds property is properly cleared when forceNew: true.

Example

...(isNewSession && {
  lastChannel: undefined,
  lastTo: undefined,
  lastAccountId: undefined,
  lastThreadId: undefined,
  deliveryContext: undefined,
  cliSessionIds: undefined,      // ← clear cliSessionIds
}),

Notes

This fix assumes that clearing cliSessionIds is sufficient to start a fresh CLI session. If additional steps are required, further investigation may be needed.

Recommendation

Apply the workaround by clearing cliSessionIds when isNewSession is true, as this directly addresses the root cause of the issue and ensures that isolated cron runs start with a fresh session.

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…

FAQ

Expected behavior

When forceNew: true, cliSessionIds should be cleared so the CLI runtime starts a fresh session:

...(isNewSession && {
    lastChannel: undefined,
    lastTo: undefined,
    lastAccountId: undefined,
    lastThreadId: undefined,
    deliveryContext: undefined,
    cliSessionIds: undefined,      // ← should be cleared
}),

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING