#23699: fix(cron): isolated sessions must generate fresh UUID on every run (#23470)
size: XS
trusted-contributor
Cluster:
Cron Job Enhancements
## Summary
Fixes #23470 — `sessionTarget: "isolated"` cron jobs reuse the same session ID across runs, breaking isolation guarantees.
## Root Cause
`resolveCronSession` only generates a new UUID when the existing session has expired (based on the reset policy). For isolated sessions, the session was still "fresh" between consecutive runs, so the same `sessionId` was reused. This caused:
- Agent seeing previous run's context ("this is the second summary today")
- Session history leaking between supposedly independent runs
## Fix
Pass `forceNew: true` to `resolveCronSession` when `job.sessionTarget === "isolated"`, ensuring a fresh UUID is generated on every execution. This is a one-line change in the call site — the `forceNew` parameter already existed but was never used for isolated jobs.
Hook-based sessions (e.g. Gmail hooks) that also use `runCronIsolatedAgentTurn` are unaffected because they don't set `sessionTarget: "isolated"`.
## Testing
All 216 cron tests pass ✅
<!-- greptile_comment -->
<h3>Greptile Summary</h3>
Fixes isolated cron session reuse by forcing fresh UUID generation on every run. The change correctly passes `forceNew: true` to `resolveCronSession` when `job.sessionTarget === "isolated"`, ensuring each isolated cron job execution gets a fresh session UUID instead of reusing the same one across runs (which was causing context leakage between supposedly independent executions).
- Adds `isIsolatedSession` boolean check for `params.job.sessionTarget === "isolated"` on line 267
- Passes `forceNew: isIsolatedSession` parameter to `resolveCronSession` on line 275
- Includes clear comment explaining the fix references issue #23470
- The `forceNew` parameter already existed in `resolveCronSession` (line 16 of `session.ts`) and is properly tested (line 126-144 of `session.test.ts`)
- No test changes needed as existing tests already verify the `forceNew` behavior
<h3>Confidence Score: 5/5</h3>
- This PR is safe to merge with minimal risk
- The fix is a minimal, surgical change that directly addresses the root cause. The `forceNew` parameter already exists and is well-tested. The change only affects isolated sessions (when `sessionTarget === "isolated"`), leaving other session types unchanged. All 216 cron tests pass according to the PR description.
- No files require special attention
<sub>Last reviewed commit: 7f22f84</sub>
<!-- greptile_other_comments_section -->
<!-- /greptile_comment -->
Most Similar PRs
#23501: fix(cron): force new session ID for isolated cron jobs (#23470)
by stakeswky · 2026-02-22
94.9%
#23562: feat: add sessionFreshness config for isolated cron jobs (#23539)
by MunemHashmi · 2026-02-22
86.1%
#20188: fix: Update sessionFile path when rolling to new session in cron jobs
by jriff · 2026-02-18
85.1%
#6315: fix(cron): persist isolated sessions (fixes #6217) - attempt 2
by ChaitanyaSai-Meka · 2026-02-01
84.7%
#15294: fix(cron): reset token counters when creating new isolated session
by Elarwei001 · 2026-02-13
83.2%
#16390: fix(cron): jobs land in wrong agent session when agentId isn't in a...
by yinghaosang · 2026-02-14
82.0%
#23086: fix(cron): surface channel resolution error for isolated sessions w...
by hydro13 · 2026-02-22
80.6%
#19385: fix: pass authProfileId from cron session to runEmbeddedPiAgent
by gigi-trifle · 2026-02-17
79.0%
#19541: fix: schedule nextWakeAtMs for isolated sessionTarget cron jobs
by guirguispierre · 2026-02-17
78.5%
#12310: cron: pass agentDir to embedded runner for isolated sessions
by magendary · 2026-02-09
78.3%