No sound through remote SSH

[0x78f1935]

Description
No sound

Steps to reproduce

1. Remotely connect to a remote server through SSH using https://marketplace.visualstudio.com/items?itemName=ms-vscode-remote.remote-ssh
2. Use claude

Expected / Actual
Sound

Environment

• OS: Windows 11
• VS Code:

1.124.0
1b50d58d73426c9171299ec4037d01365d995b78
x64

• Extension version: V3.3.2
• Install method: Marketplace

Configuration

    "claudeNotifier.minTaskDurationThreshold": 0,
    "claudeNotifier.asksQuestion.sound": "Windows Notify",
    "claudeNotifier.needsPermission.sound": "Windows Notify",
    "claudeNotifier.taskCompleted.sound": "Windows Background",
    "claudeNotifier.soundVolume": 1,

I am connected to a Debian machine, and tried different sounds, but no luck.

Claude Notifier output channel log
No output, the plugin is installed on the remote machine through Remote - SSH

Already tried

• Reloaded the VS Code window
• Reset the sound preset to a default
• [] Walked the /test-notifier Diagnostics fault tree

[ashmitb95]

Thanks for the report — this is the same remote-audio limitation tracked earlier in #3 (fixed via #6). On a remote host, webview audio is blocked by Electron's autoplay policy, so the extension falls back to the terminal bell (BEL).

The catch: in recent VS Code (you're on 1.124), terminal.integrated.enableBell only controls the visual bell. The audible bell moved to accessibility.signals.terminalBell.sound, which our fallback wasn't setting — so on your setup the bell was silent. A fix to enable both is on the way.

In the meantime, can you:

Set "accessibility.signals.terminalBell": { "sound": "on" } in your settings, make sure an integrated terminal is open, and confirm whether you now hear the bell.
Run the /test-notifier diagnostics fault tree — your report notes that step was skipped, and the output channel showing "No output" suggests we should confirm the signal is even reaching the extension on the remote.
Note the terminal bell only rings when an integrated terminal exists/has focus, so it's a coarser signal than local playback — but it should be audible once the setting above is on.

[0x78f1935]

"accessibility.signals.terminalBell": { "sound": "on" }

I've enabled this setting in my configuration and I can confirm I have a terminal bell sound in the terminal.
However, the notify extention is not making a notification sound whenever claude requires input.
I do have a couple of issues / remarks with this workaround, perhaps take those into consideration.

1. using this method you are most likely unable to change the sound, what I mean with that is that I cannot use a windows notify sound. It will always be the terminal bell sound of vsc.
2. Whenever I type in the terminal and I do a backtick on an already empty line, I now have this terminal bell yelling at me that the line is empty, instead of it being a dedicated sound for the notification extention.

Run the /test-notifier diagnostics fault tree

Where can I run this command? If I'm suppose to run it in the claude extention, there is no such command.

[pedoc]

Hi,thank you for your excellent work. Here I would like to share a situation.

If the remote Linux machine uses the GNOME desktop, the sound will occur on the remote machine, not the local one.
You can only hear the sound (such as when clicking the preview button) after connecting remotely via mstsc.

Is this expected? Is it possible to have an option to force redirect to local?

[ashmitb95]

@pedoc yes, this was a known limitation of the extension since there was no way to route notifications on a remote host back to a local machine. Did a little bit of digging and implemented a solution around a local listener waiting on remote session writes to wire notifications back on the local machine

What it does: instead of playing on the remote (where you currently only hear it through the mstsc audio bridge), the notifier pushes each notification sound to a tiny helper — cn-daemon — running on your local machine, which plays it there with your normal presets and volume. No remote audio, no terminal bell.

One caveat for your setup: the remote reaches your local daemon over an SSH reverse forward (RemoteForward in ~/.ssh/config). Your screenshot suggests an mstsc/RDP session — if you also have SSH access to that box, this works fine: just keep a background SSH connection open with the forward, alongside your RDP session. If it's strictly RDP with no SSH at all, it won't apply as-is (RDP doesn't set up the reverse tunnel).

Setup (full guide: docs/REMOTE_HOSTS.md):

Download the binary for your local machine from the release. Since you connect from Windows (mstsc), that's cn-daemon-windows-amd64.exe.
Run it locally — it listens on 127.0.0.1:47291.
Add RemoteForward 47291 localhost:47291 to that host in your local ~/.ssh/config, then connect over SSH.
On the remote, turn on claudeNotifier.remoteAudio.enabled — Settings, or run Claude Notifier: Set up remote audio… from the Command Palette, which also opens the download and shows the forward line.
Notification sounds (task done / permission / question) will then play on your local machine. Could you confirm whether you have SSH access to that box? If so I'll help you wire it up.

cc @0x78f1935
This should resolve things for you as well.

One note: I tested this end-to-end on a remote Debian instance running over Docker (sshd inside the container standing in for the remote host):

Connected to it via VS Code Remote-SSH — which confirmed VS Code honors the RemoteForward line from ~/.ssh/config, not just plain ssh.
Ran cn-daemon on my local machine and the actual notifier hooks inside the container with remoteAudio enabled.
Fired each event — question, permission, and task-done — and confirmed the right sound played on the local machine at the configured volume, over the SSH reverse forward. The container has no audio device, so the sound could only have come from local — nothing played on the remote.
I also verified the reverse forward works over plain ssh -R (for non-VS-Code/terminal setups), and the daemon cross-compiles cleanly to the 5 published platforms. The push path and dispatch wiring are covered by unit tests.

[ashmitb95]

lmk if you need further help setting this up.

Shipped in v3.5.0

Cheers!

[ashmitb95]

@agrigoriev flagging this for you as well, since yours was the original contribution adding support for remote hosts.
Hope it works :)