[Nawid3333]

This adds a daily reminder, by issue, when a new WSL version is out, so you can update WSL on your PC. You asked for this tonight.

It ships nothing: merging it doesn't release.

Why

pnpm run verify:linux runs in WSL. Before every run, tools/linux/setup.sh updates the Ubuntu inside WSL (apt, Node, Firefox, actionlint). Nothing updates WSL itself, and GitHub can't reach your PC to do it. Your PC has WSL 2.7.14; 3.0.1 came out yesterday.

What it does

.github/workflows/wsl-releases.yml runs once a day (06:00 UTC), and on demand from the Actions tab:

• It reads microsoft/WSL's latest release. Pre-releases don't count.
• A version it hasn't told you about: it opens an issue, "WSL update: ", assigned to you and @mentioning you, so it's emailed. The issue has the commands: wsl --version, wsl --update, wsl --shutdown, and wsl --update --web-download in case the update hasn't reached you yet.
• You close the issue once you've updated, or to skip that version. GitHub can't see which WSL you have, so it can't close on its own. A title is never used twice, so a closed one stays closed.
• A newer release closes the open issue, pointing to the new one. This check runs every day, so an older issue whose close failed once is closed the next day. An issue for a newer version than the latest release (should that release ever go back) stays open. Versions compare as numbers, so 2.10 is newer than 2.9.
• If the workflow itself fails: one "WSL releases workflow failed" issue, like the toolchain workflow's.

After the merge I'll run it once by hand, so the 3.0.1 issue arrives tonight, not at 06:00 UTC tomorrow.

Security

• permissions: issues: write only. It has no checkout, and runs only on its schedule or when started by hand, never on pull requests.
• The release data comes from another project. Only a tag that is a plain version number (^[0-9]+(\.[0-9]+){1,3}$) is used, in the title and a link built from it. Anything else fails the run and opens the failure issue.

Docs

• docs/maintenance.md: a row in the update-source table, and the failure issue added to "An issue from a watcher".
• CLAUDE.md: an entry next to reminders.yml.

The new row and entry sit away from the lines #71 and #72 change, so the three merge in any order.

Checks

• actionlint 1.7.12 with shellcheck (the versions ci.yml pins), in WSL: clean.
• A dry run of both steps in WSL: the scripts as taken from the YAML, a stub gh serving canned JSON through the real jq, and every create and close logged. 14 scenarios, all as intended:
  • a first run opens the issue;
  • an open or a closed issue with that title: nothing new is opened;
  • a newer release closes only the open older issue;
  • an older issue still open on a later day (its close failed): closed then;
  • the latest release gone back to an older version: the newer version's open issue stays;
  • 2.10.0 against 2.9.1: compared as numbers;
  • an issue with that title opened by a person, or a pull request by the bot: neither counts;
  • a hostile tag, or one with a v prefix: refused;
  • no publish date: "date unknown";
  • the failure report opens once, not while one is open.
• The issue filter checked against this repository with gh's own jq: it finds Toolchain update: Node.js 24 #11 ("Toolchain update: Node.js 24", closed).
• Review: GLM 5.3 flash reviewed the workflow, with three findings:
  • Fixed in the second commit: a close that failed once would have left the older issue open for good.
  • Rejected: env.PREFIX doesn't work in gh's built-in jq. The run against this repository above uses exactly that filter and finds Toolchain update: Node.js 24 #11.
  • Left as is: a failure issue older than the newest 200 open issues could be missed, which opens a duplicate. toolchain-updates.yml does the same, and this repository has about 70 issues in total.

🤖 Generated with Claude Code