Thanks for taking this on — the cross-platform coverage is solid and the overall design is sound. In particular, deriving silent-start from the persisted desktop-settings.json (rather than a launch flag) is the right call, which is why registering the bare os.Executable() path for auto-start is correct. The persistence surface is also safe: HKCU (no elevation), exec.Command with an argv array (no shell injection), and removable via disable. I also confirmed this does not touch any prompt-cache-sensitive surface (tool schema bytes/order, provider serialization, system prompt).

Before merging, please address the following.

Blocking

1. Tray "Quit" doesn't quit the app. In tray_windows.go, the cmdQuit branch calls PostQuitMessage(0) (which only exits the tray's own message loop) followed by an empty go func(){}. The app process keeps running with no window — clicking Quit just removes the tray icon. It should call wailsRuntime.Quit(t.ctx).

2. Data race in desktop_settings.go. setDesktopSettings reads the package-global ds.AutoStart without holding dsMu (if s.AutoStart != ds.AutoStart), while getDesktopSettings/loadDesktopSettings both guard ds with the mutex. go test -race will flag this — please read the previous value inside the lock.

3. No tests, and the path-semantics change is untested on the platform it affects. This PR adds zero _test.go coverage. The resolveIn/resolveCustomPaths changes only alter behavior on Windows (where /foo and \foo are now treated as absolute), but the existing TestResolveIn cases are all platform-neutral, so Linux CI never exercises the new os.IsPathSeparator(p[0]) branch. Please add focused regression tests for: auto-start register/unregister path construction, the desktop-settings persistence round-trip, and the new Windows-rooted path branch.

4. Scope creep. The workspace.go / skill.go filepath.IsAbs fixes are unrelated to auto-start. They are a defensible Windows path-consistency fix (and Linux behavior is unchanged), but bundling them here makes the PR harder to review and they ship without tests. Please either split them into a dedicated PR, or keep them here with the regression test from (3) plus a short comment explaining the Windows rationale. For the record, resolveIn honors absolute paths by design (the write-confiner, not resolveIn, enforces the workspace boundary), so this is not a new escape — but it does widen what counts as "absolute" on Windows, which is exactly why it deserves an explicit test.

Suggestions (non-blocking)

• toggleWindow only ever shows the window (the comment admits it cannot hide); tracking visibility would make the left-click toggle behave as its name implies.
• removeIcon deletes the icon without NIF_GUID, but it was added with a GUID. On Windows 10+ the delete may not match the registered identity and can leave a stale icon — include the GUID in the delete NOTIFYICONDATA.
• The registered exe path is not quoted/escaped (Windows registry value, macOS plist XML, Linux desktop Exec=). Low risk since the path comes from os.Executable(), but quoting/escaping is more robust for paths containing spaces or special characters.

Also, the PR is currently CONFLICTING against main-v2 — please rebase onto the latest origin/main-v2.

Once these are addressed and CI stays green, I'll be happy to merge this into main-v2.

#2573 is a real ask and the Win32 tray work is better than most hand-rolled attempts (icon parsing, GUID, TaskbarCreated re-add). Blockers:

1. Tray Quit never quits the app: wndProc's cmdQuit posts PostQuitMessage to the tray loop, and the follow-up goroutine contains only comments — wailsRuntime.Quit(t.ctx) is never called. Quit kills the icon and leaves the app running.
2. Quote the exe path written to the Run key — unquoted paths with spaces fail to launch.
3. setDesktopSettings reads ds.AutoStart without holding dsMu — data race.
4. Split the unrelated internal/skill + workspace path changes into their own PR; delete the commented-out NIM_SETVERSION line.
5. toggleWindow always shows and never hides (the comment admits it) — fine to defer, but say so in the description.

Both settings defaulting to off is the right call. Rebase onto current main-v2, push, and we'll approve-and-run fork CI.