Release v0.9.8.1

Downloads

macOS (Universal) - Supports both Apple Silicon and Intel

Option 1: Installation Script (Recommended)

Install with a single command (version v0.9.8.1):

curl -fsSL https://raw.githubusercontent.com/Leadaxe/singbox-launcher/develop/scripts/install-macos.sh | bash -s -- v0.9.8.1

The script will:

• Download the release archive
• Extract and install to /Applications/
• Fix macOS quarantine attributes and permissions
• Launch the application automatically

Option 2: Manual Installation

1. Download: singbox-launcher-v0.9.8.1-macos.zip
2. Extract the ZIP file
3. Remove quarantine attribute (required):

   xattr -cr "singbox-launcher.app" && chmod +x "singbox-launcher.app/Contents/MacOS/singbox-launcher"

4. Double-click singbox-launcher.app to run
   • If macOS blocks the app, go to System Settings → Privacy & Security and click "Open Anyway"
   • Alternatively, right-click the app and select "Open" (first time only)

Windows (amd64)

1. Download: singbox-launcher-v0.9.8.1-win64.zip
2. Extract the ZIP file to a folder, for example: C:\Program Files\singbox-launcher\
3. Run singbox-launcher.exe from that folder
   • You may need administrator rights to install to Program Files
   • The launcher will automatically download sing-box and wintun.dll on first launch

Windows 7 (x86, legacy)

1. Download: singbox-launcher-v0.9.8.1-win7-32.zip
2. Extract the ZIP file to a folder and run singbox-launcher-win7-32.exe
   • For Windows 7 / 32-bit or legacy compatibility only

Linux Support

⚠️ Linux build temporarily unavailable - мы ищем тестировщика для ручного тестирования перед включением автоматической сборки.

Checksums

See checksums.txt for SHA256 checksums of all files.

v0.9.8.1 — 2026-05-27

TLDR

Hotfix on top of v0.9.8 — user-defined SRS rules now actually work end-to-end. Before this release a user-added SRS rule would either lose its downloaded .srs file at the next rebuild (orphan GC mismatched filename), or — after the file-name fix — reopen the rule editor and find the type silently switched to "Custom JSON" with an empty body. Both paths are closed; no other behavior changes.

Everything from v0.9.8 is included — see the v0.9.8 release notes.

EN

Highlights

• User-defined SRS rules no longer lose their downloaded file (issue #77). Three independent code paths used three different naming conventions for the same user-SRS file — downloader saved under the URL-derived tag, build pipeline looked it up under a label-derived name, and the orphan GC's known-tags set didn't include user-SRS rules at all. Result: the actually-downloaded file was deleted at the next rebuild, and sing-box failed config-check with "cannot find file". All three paths now share the same URL-derived filename (SRSTagFromURL(url)), matching how preset-library SRS files have always worked. Bonus: two rules pointing at the same URL deduplicate to one file on disk; renaming a rule no longer invalidates the cache.
• SRS rule editing: re-open now correctly shows the SRS type and source URL. When you saved an SRS rule and reopened it for edit, the dialog was falling back to "Custom JSON" with an empty body — because the v6→legacy conversion didn't include a rule_set hint in the rule body that the dialog's type detector keys off of. Fixed.

Technical / Internal

• SPEC 063 — refactor: identity computed, not stored. The redundant state.Rule.ID field is dropped from the state schema. Rule identity is now a pure function (state.StableRuleID(r)) computed from body.name (for inline/srs) or Ref (for preset). Legacy state.json with "id":"…" still loads cleanly — Go JSON ignores unknown fields; the next Save no longer emits it. Single source of truth for SRS filenames on disk: build.SRSTagFromURL(URL) — shared by downloader, build pipeline, and orphan GC. See SPEC 063.
• Test coverage for issue #77. New core/build/srs_filename_test.go asserts URL-derived filename in all 3 call sites + dedup (2 rules, same URL → one file) + rename safety (label change doesn't break cache). Future regressions on CollectSrsCachedPaths will fail tests instead of shipping silently.

RU

Основное

• Пользовательские SRS-правила больше не теряют скачанный файл (issue #77). Три независимых пути в коде использовали три разные конвенции для имени одного и того же файла user-SRS — downloader сохранял под URL-derived тегом, build pipeline искал под label-derived именем, а orphan GC вообще не включал user-SRS в known-tags. Результат: реально-скачанный файл удалялся при следующем rebuild, и sing-box падал в config-check с "cannot find file". Теперь все три пути используют одно и то же URL-derived имя (SRSTagFromURL(url)) — тот же подход, что всегда работал для preset-library SRS. Бонус: два правила с одинаковым URL дедуплицируются в один файл на диске; переименование правила больше не инвалидирует кеш.
• Редактирование SRS-правила: при повторном открытии корректно показывается тип SRS и исходный URL. При сохранении SRS-правила и его повторном открытии диалог fallback'ался на «Custom JSON» с пустым body — потому что v6→legacy конверсия не клала rule_set хинт в тело правила, по которому детектор типа в диалоге распознаёт SRS. Поправлено.

Техническое / Внутреннее

• SPEC 063 — refactor: identity вычисляется, не хранится. Избыточное поле state.Rule.ID удалено из state schema. Identity правила теперь pure function (state.StableRuleID(r)), вычисляемая из body.name (для inline/srs) или Ref (для preset). Legacy state.json с "id":"…" грузится без ошибок — Go JSON игнорирует неизвестные поля; следующий Save их не эмитит. Единый источник правды для filename'ов SRS на диске: build.SRSTagFromURL(URL) — общий у downloader, build pipeline и orphan GC. См. SPEC 063.
• Тестовое покрытие issue #77. Новый core/build/srs_filename_test.go проверяет URL-derived filename во всех 3 точках + дедуп (2 правила с одинаковым URL → один файл) + rename safety (изменение label не ломает кеш). Будущие регрессии в CollectSrsCachedPaths будут падать тестами, а не молча уезжать в релиз.