When using VRChat's Hold-to-Talk (Push-to-Talk) microphone mode, the OSC/OSCQuery MuteSelf parameter does not appear to reliably reflect whether the microphone is currently transmitting audio. I encountered this behavior while using two independent VRChat speech transcription and translation applications, VRCS and VRCT , both of which support synchronization with VRChat's microphone mute state. Other microphone modes, including Always On, Always Off, and Toggle, appear to work as expected. The problem occurs specifically with Hold-to-Talk. ### Steps to Reproduce Launch VRChat on Windows in PCVR mode and enable OSC. Configure an external application that monitors /avatar/parameters/MuteSelf via OSC/OSCQuery. Set VRChat's microphone behavior to Hold-to-Talk. Speak without holding the Push-to-Talk button. Observe the mute state reported to the external application. Press and release Push-to-Talk and observe whether the reported state changes accordingly. Repeat the test using Always On, Always Off, and Toggle microphone modes. Compare the behavior using VRCS and VRCT. ### Expected Behavior External applications should be able to determine whether the microphone is currently allowed to transmit audio. Ideally, MuteSelf would reflect the effective microphone mute state, including Hold-to-Talk behavior. Alternatively, if MuteSelf is intentionally designed to represent only the persistent mute state, VRChat should provide a separate read-only OSC/OSCQuery parameter indicating the effective microphone transmission or Push-to-Talk state. ### Actual Behavior With Hold-to-Talk enabled, external applications may treat the microphone as unmuted even while the Push-to-Talk button is not being held. As a result, speech transcription and translation applications can automatically publish microphone transcriptions through the VRChat OSC Chatbox, even though the user's voice is not being transmitted through VRChat voice chat. This behavior was reproduced with both VRCS and VRCT. Other microphone modes appeared to work correctly. ### Impact This is potentially a privacy issue for users of speech-to-text, translation, accessibility, and subtitle applications. Users may reasonably expect speech spoken while Push-to-Talk is released to remain private. However, if external applications rely on MuteSelf for synchronization, those conversations can unintentionally appear in the public Chatbox. ### Environment Platform: Windows PCVR Headset: Meta Quest 3 Microphone behavior: Hold-to-Talk OSC/OSCQuery: Enabled Tested applications: VRCS and VRCT VRChat build: [To be filled in] PCVR streaming software: [To be filled in] ### Additional Notes I understand that MuteSelf may intentionally represent the persistent mute setting rather than the effective Push-to-Talk transmission state. If so, I would appreciate clarification of the intended behavior and consideration of a dedicated read-only OSC/OSCQuery parameter exposing whether microphone transmission is currently active. Such a parameter would allow third-party subtitle and translation tools to implement reliable Push-to-Talk-aware privacy controls.
