Problem
The open issue list has a real backlog-cleanup problem, but a blanket "close anything older than one month" rule would close the wrong things.
A safer policy is needed:
- close issues that are waiting on reporter info and inactive;
- consolidate duplicate roadmap/request clusters into active epics;
- preserve release blockers, current milestone work, security, and intentional v0.9.0 roadmap issues.
Right now the repo appears to have stale automation, but it is effectively not active for current issues because the labels it depends on are not present and bug reports are exempt even when they are explicitly waiting on info.
Evidence
.github/workflows/stale.yml exists and uses actions/stale@v9 with:
days-before-stale: 14
days-before-close: 7
only-labels: 'needs-info'
stale-issue-label: 'stale'
exempt-issue-labels: 'pinned,keep-open,bug,security'
- Current label inventory includes
bug, documentation, duplicate, enhancement, invalid, needs-human, question, security, wontfix, but not needs-info, stale, pinned, or keep-open.
- Query snapshot on 2026-06-11:
- first 300 open issues inspected;
- 40 were created before 2026-05-11;
- only 19 were also last updated before 2026-05-11;
- many older roadmap issues were updated on 2026-06-10 or 2026-06-11, so creation date alone is too aggressive.
- Examples of old untouched issues that look like manual triage candidates, not immediate blind closures:
- Duplicate/request clusters that should be consolidated rather than left as independent roadmap items:
- GUI / VS Code / web UI requests:
#735, #860, #875, #1132, #1264, #1343 overlap with active epics such as #461, #480, #481, and #2580.
- Mascot/companion requests:
#1063 and #1249 overlap partially but differ between an optional command/pet and startup mascot; maintainer should decide whether to merge, defer, or keep one canonical issue.
- OPENCODE micro-issues:
#411, #412, #413, #414, #424, #425, #426, #427, #431, #452, #457, #458, #459, #470 are old v0.9.0 roadmap shards; either label as intentionally kept or roll into a smaller epic index.
Proposed direction
- Create or normalize the stale-policy labels used by automation:
needs-info
stale
keep-open
pinned if the repo wants that label name, or update the workflow to use existing labels.
- Adjust
.github/workflows/stale.yml so needs-info issues can actually close after inactivity:
- keep
only-labels: 'needs-info';
- do not exempt all
bug issues once they are explicitly labeled needs-info;
- keep exemptions for
security, release-blocker, keep-open, and pinned.
- Add a first manual triage pass before automation starts closing anything:
- label unresolved stale bug reports as
needs-info with a current-version repro request;
- close obvious discussion/duplicate issues with links to canonical epics;
- mark intentional roadmap shards with
keep-open or consolidate them into an epic and close the shards.
- Use
updatedAt and labels as the closure basis, not createdAt alone.
Acceptance criteria
Verification
Suggested dry-run queries:
gh issue list --state open --search 'updated:<2026-05-11' --limit 100 --json number,title,updatedAt,labels,url
gh issue list --state open --search 'label:needs-info updated:<2026-05-28' --limit 100 --json number,title,updatedAt,labels,url
gh issue list --state open --search 'created:<2026-05-11 comments:0 -label:keep-open -label:release-blocker -label:security' --limit 100 --json number,title,createdAt,updatedAt,labels,url
Manual verification after workflow/label changes:
- Add
needs-info to a test/noncritical issue or run actions/stale in dry-run mode if adopted.
- Confirm the issue receives the stale warning after the configured inactivity window.
- Confirm protected labels prevent closure.
- Confirm PRs are still untouched by stale automation.
Problem
The open issue list has a real backlog-cleanup problem, but a blanket "close anything older than one month" rule would close the wrong things.
A safer policy is needed:
Right now the repo appears to have stale automation, but it is effectively not active for current issues because the labels it depends on are not present and bug reports are exempt even when they are explicitly waiting on info.
Evidence
.github/workflows/stale.ymlexists and usesactions/stale@v9with:days-before-stale: 14days-before-close: 7only-labels: 'needs-info'stale-issue-label: 'stale'exempt-issue-labels: 'pinned,keep-open,bug,security'bug,documentation,duplicate,enhancement,invalid,needs-human,question,security,wontfix, but notneeds-info,stale,pinned, orkeep-open.#1093suspicious/malformed URL-title bug report.#802,#805,#945,#1102,#1165,#1198,#1251old terminal/Windows/TUI bug reports that likely need current-version repro requests first.#1254brand/DeepSeek discussion likely superseded by the CodeWhale rebrand and README/history work (v0.8.65 end-cap: Rewrite README with CodeWhale history, Fleet, and provider routing map #3087), but should be closed with a clear maintainer note.#735,#860,#875,#1132,#1264,#1343overlap with active epics such as#461,#480,#481, and#2580.#1063and#1249overlap partially but differ between an optional command/pet and startup mascot; maintainer should decide whether to merge, defer, or keep one canonical issue.#411,#412,#413,#414,#424,#425,#426,#427,#431,#452,#457,#458,#459,#470are old v0.9.0 roadmap shards; either label as intentionally kept or roll into a smaller epic index.Proposed direction
needs-infostalekeep-openpinnedif the repo wants that label name, or update the workflow to use existing labels..github/workflows/stale.ymlsoneeds-infoissues can actually close after inactivity:only-labels: 'needs-info';bugissues once they are explicitly labeledneeds-info;security,release-blocker,keep-open, andpinned.needs-infowith a current-version repro request;keep-openor consolidate them into an epic and close the shards.updatedAtand labels as the closure basis, notcreatedAtalone.Acceptance criteria
.github/workflows/stale.ymlis updated to use labels that exist.bugissue labeledneeds-infois eligible for stale close unless it also hasrelease-blocker,security,keep-open, orpinned.keep-open/epic-linked) or closed as superseded.Verification
Suggested dry-run queries:
Manual verification after workflow/label changes:
needs-infoto a test/noncritical issue or runactions/stalein dry-run mode if adopted.