Windows app: per-app volume is lost on every update (60 stale mixer entries), and a wrong level is invisible in-app

Status Closed — not planned
Maintainer reply None cached
Activity 1 comment · opened Aug 24, 2026 · closed Aug 28, 2026

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.exe session volume: 4%
  • chrome.exe session 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

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

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

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

  1. Clean up the stale per-app entries an update leaves behind, or migrate the previous

version's level forward.

Repro

  1. Note the app's level in the Windows Volume Mixer while it is playing a sound.
  2. Set it to something distinctive, say 40%.
  3. Let the app update.
  4. 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.

View original on GitHub ↗

This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗