← Back to PRs

#23699: fix(cron): isolated sessions must generate fresh UUID on every run (#23470)

by echoVic open 2026-02-22 16:15 View on GitHub →
size: XS trusted-contributor
## 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