Bug Reports

When tabbed out of VRChat (Irregardless of how it was done, tab, windows key, etc.) the cursor will remain active on screen at all times. If this is a intended feature, it would be greatly displeasing for streaming type content. This only started with the new UI update, so I'd assume it has something to do with the new HUD elements (Specifically on Desktop).

In the latest SDK Update 3.10.5 whenever any physbones get toggled off and on again in play mode they do not disable and instead have the settings you have set applied again over the Physbones over and over again each time they are toggled off and on. It doesn't happen in game thankfully but in unity when trying to test Phys bone settings, enabling and disabling the Physbones or their bones no longer works correctly. Downgrading to 3.10.4 fixes the issue so I've been staying on that version for now but I'm worried about this bug staying in the sdk especially when I will eventually have to update for the face tracking update. To reproduce and see it obviously just have a physbone chain with some gravity and gravity falloff on it and in play mode toggle to the physbone script off and on again a few times and you'll see the gravity getting multiplied each time its toggled off and on might have to have reset when disabled turned off and animated physbones turned on aswell

The latest beta update seems to have silently added a new OSC endpoint /avatar/name that sends out the avatar's name. This breaks when the avatar's name has complex UTF-8 characters. The characters seem to get truncated to a single byte, which most OSC applications cannot correctly decode. Debug menu "Version & Info": S:Release_1626 V:2026.4.1 This is extremely easy to reproduce with any avatar that has a ! in its name, as that character gets transformed to U+01c3 on upload, which then gets truncated to a c3 byte when sent over OSC, which cannot be decoded as valid UTF-8 (or ascii) This is even more noticeable with avatars that contain Japanese character in their names.

unable to type/edit invite reply with hand quickmenu is stuck to. can only type with other hand, while having to weirdly hold my right hand out of the way. it also behaves weirdly when saving/confirming. Edit: this has been around since the keyboard beta launched lol, I imagine myself and many others fell into the deceptively comfy state of "surely someone else already posted this on canny."

Creating a group calendar event fails with a 500 on 10 of 19 calls since 2026-10-11. The request bodies differ only in title, description and times, so the same request succeeds or fails at random. We hit this in the test suite for the community API specification . Three workflows create an event in a group they created a second earlier, and nothing else touches the group in between: group-calendar-lifecycle calendar-event-lifecycle update-instance-calendar-link-lifecycle CI runs with failures: 10-11 15:19 , 10-12 14:07 , 10-12 15:51 , 10-12 16:37 , 10-12 16:46 Request POST /api/1/calendar/{groupId}/event {"accessType":"group","category":"other","description":"Created by the test suite","title":"Test","sendCreationNotification":false,"startsAt":"2026-10-12T17:47:40.171Z","endsAt":"2026-10-12T18:47:40.249Z"} Response ( 500 ) {"error":{"message":"Application error","status_code":500}} Every call, failed or successful, reached build master-build-2026-10-09-pill-j-spearpide in the blue group. Failed (UTC, x-vrc-request-id) 2026-10-11 15:20:58 mv3z089tgsuw9nzz 2026-10-12 14:08:57 mv5bvgc4nuawh5dm 2026-10-12 14:10:17 mv5bx5v6d0z76z52 2026-10-12 15:51:53 mv5fjtszv0x2g0th 2026-10-12 15:53:00 mv5fl9h6ngz2zmri 2026-10-12 16:47:36 mv5hjgyovnpclfeo 2026-10-12 16:47:42 mv5hjll1pcaioy4c 2026-10-12 17:08:18 mv5ia3v5lfpuol7i 2026-10-12 17:08:25 mv5ia99065rllitv 2026-10-12 17:09:33 mv5ibpsv2bdb9mmw Succeeded (UTC, x-vrc-request-id) 2026-10-11 15:19:54 mv3yyugez7oprqpu 2026-10-11 15:20:03 mv3yz131x21o6lk5 2026-10-11 15:20:58 mv3z07nhrbz7n8up 2026-10-12 14:08:41 mv5bv4pavr7esmdy 2026-10-12 14:10:14 mv5bx48cht0bpi59 2026-10-12 14:10:15 mv5bx4rqf8bnxqc4 2026-10-12 15:51:59 mv5fjyt87luswyi7 2026-10-12 15:52:58 mv5fl7o3qzjcrdi7 2026-10-12 15:52:58 mv5fl8d9budkxp4g

Summary If an OSCQuery-enabled app on the same PC is already advertising when VRChat starts, VRChat discovers it during startup, before login, and fails with a NullReferenceException while creating the OscClient. No “VRChat is going to send data to …” HUD notification is shown. OSC data is still delivered to the app (avatar parameters and /avatar/change arrive), so only the client setup or notification step seems to fail. If the app is started after VRChat has finished starting, it is discovered without errors and the HUD notification appears. Environment VRChat 2026.4.1-1931-68b4616cf3-Release (Steam), Windows 11 OSCQuery app on the same PC, advertising _oscjson._tcp and _osc._udp on 127.0.0.1 (python-zeroconf / tinyoscquery) Steps to reproduce Start an OSCQuery app that advertises an /avatar endpoint (e.g. /avatar/parameters/MuteSelf). Start VRChat with OSC enabled. Watch the HUD after logging in, and check the output log. Expected The app is registered and the HUD notification is shown, the same as when the app is started after VRChat. Actual No HUD notification. The output log shows this during startup (while the login UI is being created, before authentication): ```log Debug - Advertising Service VRChat-Client-XXXXXX of type OSCQuery on 53316 Debug - Advertising Service VRChat-Client-XXXXXX of type OSC on 9000 Debug - [Behaviour] creating login UI Debug - Found new OSC Service: <app>:<id> at 127.0.0.1:63269 Debug - Found new OSC Service: <app>:<id> at 127.0.0.1:63269 Debug - [Behaviour] authenticating Debug - Found OSC Client of type 0 Debug - Found OSC Client of type 2 Error - Could not make new OscClient: Object reference not set to an instance of an object. Debug - Found OSC Client of type 0 Debug - Found OSC Client of type 2 Error - Could not make new OscClient: Object reference not set to an instance of an object. ``` Frequency 7 out of 7 launches with the app started first. 0 errors when VRChat was started first. In that case the app was discovered about 2 minutes after startup, and the notification appeared. Notes Discovery happens about 1 second after VRChat starts its own OSCQuery service, while the login UI is still being built. Something used when creating the OscClient (possibly the HUD or notification system) seems not to be initialized yet. Similar log line, different cause (remote PC / request failure): “Osc being discovered on non-local pc” and vrchat-community/osc#169( https://github.com/vrchat-community/osc/issues/169 ).

OnPlayerTriggerEnter, OnPlayerTriggerExit and OnPlayerTriggerStay DO NOT FIRE when the player is in a station. This breaks events, manual culling, zone switching, and thousands of other map features across the entire game, when a player simply gets in a chair. I had to give up on a zone culling system because a map had vehicles and was not about to implement a custom Trigger Enter event solution (I did but it only supported axis aligned cubes) This was bug reported in 2021 and it's still not fixed!!! It's 2026 guys let my maps work correctly please!!!

After last night’s update (1919), using the triggers to interact with anything (UI, world objects, etc.) on Steam Frame Standalone requires an excessively hard pull of the trigger. This was not the case before the most recent update and makes doing literally anything much harder. To make matters worse, going to controller settings in the in-game menu simply displays a screen that you’re using an unrecognized controller with no options to fix it. This issue only applies to the standalone build of VRChat on Frame. Frame controller trigger sensitivity remains consistent with prior builds when streaming from a PC.

Description i can't see what i type until after im done typing, it just doessnt appear but it registers, it happens every time ive opened my chat box Reproduction Steps it just keeps happening and i cant see what im typing T all and it always happens with this new chat system so i can't type Details Category: Other Frequency: Always --- platform: AndroidMobile (platform: Android - Mobile, store: PlayStore, headset: None) rawPlatform: Android clientVersion: 2026.3.3-1919-27c41b24d2-Release unityVersion: 6000.0.67f1-DWR In-Client Report --- Log file: output_log_2026-10-05_23-03-11.txt

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.