Leadaxe/singbox-launcher v0.9.5

release v0.9.5

on GitHub

Release v0.9.5

Downloads

macOS (Universal) - Supports both Apple Silicon and Intel

Option 1: Installation Script (Recommended)

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

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

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.5-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.5-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.5-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.

Highlights (EN)

Single-fix point release continuing the cleanup of the dual-storage residue from SPEC 045/052 refactor. After v0.9.4 fixed route.final losing the user's choice on Save, this release fixes the same architectural class for per-source outbounds in Configurator → Outbounds tab.

Fixed

• Configurator → Outbounds: per-source outbound now persists across Save. Reported by Michael M. Adding a new outbound with any Scope ≠ "For All" produced no persistent change after Save (entry vanished from the list). Editing an existing outbound and switching Scope from "For All" to a source-specific one had the same symptom — entry disappeared. Same root cause as the v0.9.4 route.final regression: the Outbounds tab is the only UI surface that mutates the legacy model.ParserConfig.ParserConfig.Proxies[i].Outbounds view directly, and the on-apply callback synced only the global outbounds back to canonical model.GlobalOutbounds — per-source outbounds had no equivalent sync, so they only existed in the derived view and were dropped at Save when presenter copied model.Sources into state.Connections.Sources. Fix is one block in onConfiguratorApply that walks model.Sources in lockstep with ParserConfig.Proxies (built 1:1 from Sources via AsParserConfig, index alignment guaranteed) and copies Outbounds back. Covers all four operations: Add, Edit (with or without scope change), Delete, Reorder ↑↓ — they all close through the same callback.

Technical / Internal

• Audit completed across remaining UI surfaces (Source edit window, Source enable/disable/delete, DNS tab, Rules tab, Settings tab) — all of them write canonical store directly, no other dual-book pattern remains. Outbounds tab was the last instance.
• Pre-existing state.json files with per-source outbounds load correctly — Sources[i].Outbounds is read on Load and projected into the derived ParserConfig view by RefreshDerivedParserConfig. The bug was strictly write-side, no migration needed.

Основное (RU)

Точечный фикс — продолжение чистки последствий двойного хранилища из рефактора SPEC 045/052. После v0.9.4, где починили потерю выбора route.final при Save, этот релиз закрывает тот же архитектурный класс для per-source outbound'ов во вкладке Configurator → Outbounds.

Исправлено

• Configurator → Outbounds: per-source outbound теперь сохраняется при Save. Сообщил Michael M. Добавление нового outbound со Scope ≠ "For All" не давало эффекта после Save (запись пропадала из списка). Редактирование существующего outbound со сменой Scope с "For All" на source-specific — тот же симптом, запись исчезала. Корень тот же что у v0.9.4 регрессии с route.final: вкладка Outbounds — единственный UI surface, который мутирует legacy view model.ParserConfig.ParserConfig.Proxies[i].Outbounds напрямую, а on-apply callback синхронизировал обратно в canonical model.GlobalOutbounds только глобальные outbound'ы — per-source эквивалентной sync не было, поэтому они существовали только в derived view и терялись при Save (когда presenter копирует model.Sources в state.Connections.Sources). Фикс — один блок в onConfiguratorApply, который идёт по model.Sources параллельно с ParserConfig.Proxies (построен 1:1 из Sources через AsParserConfig, выравнивание индексов гарантировано) и копирует Outbounds обратно. Покрывает все четыре операции: Add, Edit (с / без смены scope), Delete, Reorder ↑↓ — все закрываются через тот же callback.

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

• Аудит остальных UI surfaces (Source edit window, Source enable/disable/delete, DNS tab, Rules tab, Settings tab) показал что все они пишут в canonical store напрямую — других дыр того же класса нет. Outbounds tab был последним.
• Существующие state.json с per-source outbound'ами загружаются корректно — Sources[i].Outbounds читается на Load и проектируется в derived ParserConfig view через RefreshDerivedParserConfig. Баг был строго на write-side, миграция не нужна.