Greptile Summary

This PR fixes a bug where isolatedSession: true on heartbeats failed to actually isolate each run's context, because the new sessionEntry spread the old entry (including its sessionFile path) before assigning a new sessionId. Since resolveSessionFilePath prefers the stored entry.sessionFile over a freshly derived path, every heartbeat continued appending to the same transcript file regardless of the new UUID.

The fix is a single targeted change: when isNewSession is true, explicitly set sessionFile: undefined in the new entry so resolveSessionFilePath falls through to its ID-based path derivation.

• The spread idiom ...(isNewSession && { sessionFile: undefined }) is correct TypeScript; it shadows the inherited sessionFile from ...entry with undefined, which is treated as absent by the truthy check in resolveSessionFilePath.
• The change is minimal and well-commented, with a direct reference to the upstream issue.
• No new test was added to assert that sessionEntry.sessionFile is undefined when isNewSession is true (e.g. the forceNew: true and stale-session tests don't verify this field), though the existing test suite passes and the logic is straightforward.

Confidence Score: 5/5

Safe to merge — single-line targeted fix with correct semantics and no risk of regressions on the non-isolated session path.

The fix is minimal, well-reasoned, and directly addresses the root cause. The ...(isNewSession && { sessionFile: undefined }) idiom correctly overrides the inherited field, and resolveSessionFilePath already handles undefined as 'no stored path' — so the behavior change is exactly as intended. The only gap is the absence of a dedicated regression test for the sessionFile clearing, which is a P2 concern at most and does not block merge.

No files require special attention.

This is a comment left during a code review.
Path: src/cron/isolated-agent/session.test.ts
Line: 126-144

Comment:
**Missing regression test for `sessionFile` clearing**

The existing `forceNew` and stale-session tests verify that `sessionId` rotates and that user-configured overrides (e.g. `modelOverride`) are preserved, but none of them assert that `sessionFile` is set to `undefined` on the new entry — which is exactly the behaviour this PR adds. Without such an assertion, a future refactor of the spread order could silently reintroduce the same bug.

Consider adding an explicit check in the `forceNew` test (and/or the stale-session test):

```ts
it("creates new sessionId when forceNew is true", () => {
  const result = resolveWithStoredEntry({
    entry: {
      sessionId: "existing-session-id-456",
      updatedAt: NOW_MS - 1000,
      systemSent: true,
      modelOverride: "sonnet-4",
      providerOverride: "anthropic",
      sessionFile: "old-uuid.jsonl",   // ← add a stored sessionFile
    },
    fresh: true,
    forceNew: true,
  });

  expect(result.sessionEntry.sessionId).not.toBe("existing-session-id-456");
  expect(result.isNewSession).toBe(true);
  expect(result.sessionEntry.modelOverride).toBe("sonnet-4");
  // Core regression guard for issue #43767
  expect(result.sessionEntry.sessionFile).toBeUndefined();
});
```

The same assertion would be valuable in the "creates new sessionId when session is stale" test.

How can I resolve this? If you propose a fix, please make it concise.

_{Reviews (1): Last reviewed commit: "fix(heartbeat): clear sessionFile on new..." | Re-trigger Greptile}