First off — I really love that this tool exists and lets Windows users catch up to macOS developers. I've been testing wmux for my work and wanted to share constructive feedback on a few things I struggled with, plus one feature suggestion. Code references included in case they help.

1. Notification sounds never play

The Sound setting (Settings → Notifications, Default/None) looks functional but is a no-op:

• notificationPrefs.sound is defined (settings-slice.ts:246-260) and shown in the UI (NotificationSettings.tsx:51-65) but never read anywhere.
• There's no audio playback code at all (no new Audio/.play()), and resources/sounds/ is empty (only .gitkeep) despite being bundled into every release.
• Only the Electron toast + taskbar flash + pane ring fire (notification-manager.ts:4-14).

Suggestion: ship a default sound asset and play it in the NOTIFICATION_FIRE path when sound !== 'none', or remove the setting until implemented so it's not misleading.

2. Proper installer / Microsoft Store distribution + PATH

The portable zip works but limits discoverability and makes PATH setup manual. electron-builder.json already has NSIS config (currently unused) and electron-builder supports MSIX/appx. Rough effort, lowest-friction first:

Code-signing is the dominant variable for the installer path:

• Cheapest modern route: Azure Trusted Signing (~$10/mo), integrates with electron-builder.
• Traditional OV cert ($200–400/yr) builds SmartScreen reputation slowly; EV ($300–700/yr) clears it immediately.
• The Store path sidesteps cert purchase entirely (Microsoft signs Store MSIX).

Suggested sequencing: Winget first (cheap, fast), then Azure Trusted Signing + the existing NSIS installer mid-term, and treat Store/MSIX as a separate spike gated on confirming the sandbox doesn't break the pipe/PTY architecture. A proper installer would also register a real wmux CLI on PATH automatically — which fixes issue #3.

3. wmux browser open launches a NEW instance instead of using the running one

When Claude Code runs wmux browser open <url> it spawns a fresh wmux window rather than driving the existing one. Two confirmed root causes:

• Stale compiled CLI: resources/cli/wmux.js:8 hardcodes const PIPE_PATH = '\\\\.\\pipe\\wmux', dropping the process.env.WMUX_PIPE support that exists in source (src/cli/wmux.ts:7). The shipped artifact predates the feature and needs a rebuild.
• No single-instance lock: src/main/index.ts has no app.requestSingleInstanceLock() / second-instance handler, so a second launch just opens another window instead of focusing the existing one.
• Underlying trigger: outside a wmux-spawned shell, wmux isn't the CLI (no WMUX_CLI env var / wmux shell function), so the name resolves to the GUI exe on PATH → new instance, args ignored. The CLI script itself never launches the GUI (on pipe failure it just prints "wmux is not running" and exits), confirming the new window comes from the exe being invoked directly.

Suggested fixes: add requestSingleInstanceLock with a second-instance focus handler; rebuild/verify resources/cli/wmux.js; ship a dedicated wmux CLI shim on PATH distinct from wmux.exe (ties into issue #2).

4. Feature request: configurable quick-launch profiles next to the + button

I'd love to configure quick-launch shortcuts next to each pane's + button — to open tools, auto-cd into directories, run a startup command, etc. This already exists in cmux as project "custom commands" (cmux.json), and Windows Terminal has the profile-dropdown precedent — wmux is well-positioned because the UI hook is already there.

Current state:

• The + already has a caret dropdown (SurfaceTabBar.tsx:272-297) but it only offers Terminal / Browser / Markdown — pure type selection.
• There are no profiles, no startup commands, and no per-tab cwd (pty-manager.ts accepts cwd but no startup command; WT import at config-loader.ts:157-178 keeps only the color scheme and discards profiles / commandline / startingDirectory).

Proposed shape:

• Profile model: { name, icon, type, shell?, cwd?, startupCommands[] } — e.g. "Backend → cd ./server, npm run dev", "lazygit", "btop".
• Two config scopes: global in settings.json (alongside the existing 45 shortcuts), and a project-level .wmux.json committed to a repo (mirrors cmux's cmux.json).
• Surfacing: populate the existing + caret dropdown with these profiles; each entry creates a surface of type in cwd running startupCommands.
• Free wins: bind any profile to the existing keyboard-shortcut / command-palette infra, and finish the WT import to pull real profiles (commandline + startingDirectory), giving WT users an instant launcher library.

Comparatively small lift (dropdown + PTY cwd/startup-command plumbing + config schema) for a high-visibility quality-of-life feature.

Thanks again for building this — happy to help test fixes or open separate issues if you'd prefer these tracked individually.