Cannot set cursor.worktreeCleanupIntervalHours greater than setTimeout's 32-bit limit (~596 hours), cleanup fires in rapid loop

[hime]

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

The WorktreeCleanupCron setting for cleanup interval overflows JavaScript’s 32-bit signed integer limit for setTimeout/setInterval when set to values above 596 hours. Setting the interval to 720 hours (2,592,000,000 ms) exceeds the setTimeout max of 2,147,483,647 ms (2^31 - 1), causing the timer to fire immediately instead of on schedule. This results in the cleanup task running in a rapid loop — 10 times within 200ms in the observed case — before re-registering with a different (seemingly truncated) interval of 72 hours.

Steps to Reproduce

1. Set the worktree cleanup interval to 720 hours (or any value above 596 hours)
2. Open Cursor IDE
3. Observe the renderer log: WorktreeCleanupCron fires repeatedly in rapid succession instead of once

Expected Behavior

The cleanup task should either:

• Run once at the configured interval, or
• Clamp/reject values above the setTimeout ceiling of ~596 hours and warn the user

Screenshots / Screen Recordings

Operating System

Windows 10/11

Version Information

Version: 2.7.0-pre.31.patch.0 (user setup)
VSCode Version: 1.105.1
Commit: d14597228f04cdf4d41fb4f76c5f4098351dc670
Date: 2026-03-07T01:52:33.394Z
Build Type: Stable
Release Track: Nightly
Electron: 39.6.0
Chromium: 142.0.7444.265
Node.js: 22.22.0
V8: 14.2.231.22-electron.0
OS: Windows_NT x64 10.0.26300

Additional Information

The root cause is JavaScript’s setTimeout/setInterval accepting a signed 32-bit integer for the delay parameter. Node.js clamps values above 2^31 - 1 (2,147,483,647 ms ≈ 596.5 hours ≈ 24.85 days) to 1 ms, causing the timer to fire immediately. The fix is to either validate the input at configuration time (reject or clamp to 596h max) or implement a recursive setTimeout pattern that chains shorter intervals to achieve delays beyond the 24.85-day ceiling.

Does this stop you from using Cursor

No - Cursor works, but with this issue

[deanrie]

Hey, great bug report. Your root cause analysis is spot on.

This is indeed JavaScript’s 32-bit setTimeout limit. The safe boundary is exactly 596 hours (2,145,600,000 ms < 2^31-1). As a workaround, set the value to 596 or below:

"cursor.worktreeCleanupIntervalHours": 596

From the logs, it looks like the system actually self-corrects to 596h after the initial burst, so the clamping logic is partly there. It just needs to kick in before the timer is set, not after. I’ve flagged this with the team. No timeline yet, but it should be a straightforward fix.

Let me know if you run into anything else.