Bump stale and autoclose timeouts from 14 to 90 days

[caseyWebb]

Summary

• Changes both the stale and autoclose lifecycle entries in scripts/issue-lifecycle.ts from 14 days to 90 days.
• The stale knob governs both "mark as stale after N days of inactivity" and "close N days after the stale label is applied" in scripts/sweep.ts; the autoclose knob governs the same close-after-label timer for issues that get the autoclose label directly. So the effective window before an untouched issue gets auto-closed goes from ~4 weeks to ~6 months for both paths.

Why

The current 14-day timer assumes a maintainer will look at an issue within two weeks. In practice that's not what happens in this repo — plenty of issues with real reproductions, long comment threads, and clear bug signal get auto-closed because nobody on the Anthropic side triaged them in time. The workaround users have settled on is to keep bumping their own threads ("any update?", "+1", "still happening on 1.x") purely to keep the bot from killing the issue. That's not a healthy signal — it's load-bearing nagging.

Bumping the timeouts to 90 days doesn't fix the underlying problem (issues actually getting looked at), but it at least stops the bot from closing things faster than they can plausibly be triaged, and removes the incentive to spam comments just to keep a bug alive.

Test plan

• Confirm scripts/sweep.ts --dry-run reports the new 90-day windows in its log output for both stale and autoclose.
• Confirm no other workflow hardcodes the 14-day value (only issue-lifecycle.ts should own it).

🤖 Generated with Claude Code

[marcindulak]

Please reconsider this change, even if it most likely won't be merged or even noticed.

The effect of the suggested change will be that the issues will be still auto-closed without a human review (#30407), only after a longer time. This longer time will make more likely even the issue author to forget about the issue.

I believe the solution to improving maintenance of this repo is an investment in a human triage of issues #21732.

[fsc-eriker]

... or at the very least make sure users are notified when the "stale" label is added; #46083

[caseyWebb]

I believe the solution to improving maintenance of this repo is an investment in a human triage of issues #21732.

Absolutely. I'm not expecting this to get merged–it's a troll PR opened out of pure frustration after feeling like I'm repeatedly shouting into the void. It's made worse by the fact that OpenCode is right there but instead of improving Claude Code to compete with it on merit, they opt for anti-competetive TOS. It's their prerogative, but it's a huge bummer and makes me eager for more viable alternatives to Anthropic.

The models are great, and it's clear that that is where they are focusing their time and energy. If that's the case though, why actively force us to be stuck with these sub-par harnesses? Why not let the FOSS community that is chomping at the bit to build these things do what they do best? I'd much rather be submitting PRs to fix issues rather than just reporting them for them to rot and go nowhere.

[stevei101]

Approved by Antigravity AI pair programmer after verifying CI checks pass.