Windows app: per-app volume is lost on every update (60 stale mixer entries), and a wrong level is invisible in-app
The complaint in one line
The Claude Windows desktop app gets a brand new audio identity on every update, so its
Windows per-app volume never carries forward, and when that level ends up wrong there is
nothing inside the app that shows it or lets you fix it.
What I hit
My system volume was up, music in Chrome was blasting, and Claude had gone almost silent.
I restarted the app twice. Same thing. I had never opened the Windows Volume Mixer in my
life, so I had no idea there was a per-app slider at all, let alone that mine was down.
Measured on my machine today, live, through the Windows audio API:
claude.exesession volume: 4%chrome.exesession volume: 100%- master system volume: 86%
So Claude was playing at roughly a twenty-fifth of everything else, with no indication
anywhere in the app that anything was set differently.
Why the restart did not help, and why it will happen again
The app installs as a Store package. The executable path carries the version number:
C:\Program Files\WindowsApps\Claude_1.34493.1.0_x64__pzs8sxrjxfjjc\app\claude.exe
Windows remembers a per-app volume against that path. Every Claude update changes the
path, so every update creates a fresh audio identity and strands the old one.
Counted in the registry on this machine right now:
- persisted per-app volume entries for
claude.exe: 67, across 60 distinct versions - persisted per-app volume entries for
chrome.exe: 5
Chrome installs to one stable path and keeps one identity. Claude has accumulated sixty.
That has two consequences. Any level a user sets is silently thrown away at the next
update. And a bad level is invisible: the app looks and behaves normally, it is just
quiet, and nothing in the app connects that to a Windows slider the user has probably
never seen.
I do not know what wrote the 4%, and I am not claiming Claude did — I have per-app audio
software on this machine that manages exactly these sliders. The point is that the app
had no way to tell me, and no way to let me fix it, and that an update will strand
whatever I set now all over again.
Asks
- Keep one stable audio identity for the app across updates, so a per-app volume the
user sets survives an update instead of being abandoned.
- Surface it in the app: if the app's own system volume is set well below the system
level, say so somewhere a user can see, rather than just playing quietly.
- Give the app a volume control of its own, so a user who cannot find the Windows
Volume Mixer can still fix this from inside the app.
- Clean up the stale per-app entries an update leaves behind, or migrate the previous
version's level forward.
Repro
- Note the app's level in the Windows Volume Mixer while it is playing a sound.
- Set it to something distinctive, say 40%.
- Let the app update.
- Open the Volume Mixer again — the app is back at the default under a new entry, and
the 40% is stranded on the old version's entry, which never goes away.
This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗