Bug Reports

Issue: I currently use the UserEyeTracking bool to enable or disable my "Ear Tracking", which moves my ears in the direction that I'm looking. As I don't have eye tracking at the moment, I turned on Disable Eye Look Tracking and Disable Eye Lid Tracking which sets this value to false locally. For remote clients how ever the value stays true. This results in my ears moving around with VRChat's automated eye look / gaze feature for remote clients. Reproduction Steps: On an Avatar with native face tracking add a simple toggle that uses the UserEyeTracking parameter. Launch the game with 2 clients in one instance. Switch into the Avatar an enable Selfie Expression. Go to the Main Menu > Settings > Tracking and IK and turn on Disable Eye Look Tracking and Disable Eye Lid Tracking . If you do this, locally your created toggle turns off, while it stays on for remote. Expected Behaviour: When turning on Disable Eye Look Tracking and Disable Eye Lid Tracking no eye look or eye lid data should be sent. Thus in return UserEyeTracking should also be false. I understand that UserEyeTracking on remote is calculated based on if Eye Look or Eye Lid data is received, but since I turned off the tracking for it in the settings I would expect it to also be false. Attachments In this screenshot I have a cube attached to my avatar that is either on or off based on UserEyeTracking . While it's off locally, you can see that it's on for remote.

It took me forever to figure this out. For some reason, advanced contact parameters (or at least sender local position, from testing) can't be used to drive AAPs. It's incredibly weird because contacts normally allow you to do that. (AAPs: https://vrc.school/docs/Other/AAPs/ ) This behavior is needed so we can apply scaling using a blendtree to multiply by ScaleFactorInverse, remap values, among lots of other uses. Here's an avatar that detects your head rotation using sender local position. Each animation moves the cube behind you and drives a HeadAngle/ AAP. The cube moves, but those AAPs don't change. You can check in the avatar debugger. https://vrchat.com/home/avatar/avtr_ec965727-67de-45b9-9476-411a27849ed2 I wonder if this has to do with the timing of contact updates...

VRChat intermittently crashes to desktop without an error dialog when joining a populated instance of Mafia Classic. World ID: wrld_80d828d2-ae5f-4fa5-aaaa-072b80096995 Other players have also reported crashes when entering this world, although their crash dumps have not been analyzed. REPRODUCTION Join a populated Mafia Classic instance. The world scene loads successfully. Player/avatar initialization begins. VRChat sometimes unexpectedly closes. Frequency: intermittent. Both empty and populated instances have also been entered successfully. EXPECTED The client completes initialization and enters the world. ACTUAL The client crashes to desktop without an error dialog. CRASH EVIDENCE I captured two crashes on October 18 and October 20, 2026. Offline analysis found the same complete 22-frame native call stack in both dumps: UnityPlayer.dll version: 6000.0.67.6863 Exception: 0xc0000005 Fault offset: 0xb11b2d Invalid read from address 0x58, with R13 = 0 Call chain enters UnityEngine.Animator::Update_Injected with zero delta time: Animator.Update(0). The final log messages in both cases concern remote avatar limb initialization. No Udon runtime exception was recorded during the failed entry. The specific Animator, avatar or world object responsible has NOT been identified. The last avatar mentioned in the log is not a confirmed cause. ENVIRONMENT VRChat 2026.3.3p2-1921-15c4a824b2-Release Windows 11, build 26200 Steam installation, Direct3D 11 NVIDIA GeForce RTX 3060 Ti, 8 GB VRAM 32 GB RAM Crash dump, full logs and detailed analysis were submitted privately through support ticket #745343. Could you investigate the native Animator.Update(0) crash path and advise what additional diagnostic information would help identify the trigger? World ID: wrld_80d828d2-ae5f-4fa5-aaaa-072b80096995 Other players have also reported crashes when entering this world, although their crash dumps have not been analyzed. REPRODUCTION Join a populated Mafia Classic instance. The world scene loads successfully. Player/avatar initialization begins. VRChat sometimes unexpectedly closes. Frequency: intermittent. Both empty and populated instances have also been entered successfully. EXPECTED The client completes initialization and enters the world. ACTUAL The client crashes to desktop without an error dialog. CRASH EVIDENCE I captured two crashes on October 18 and October 20, 2026. Offline analysis found the same complete 22-frame native call stack in both dumps: UnityPlayer.dll version: 6000.0.67.6863 Exception: 0xc0000005 Fault offset: 0xb11b2d Invalid read from address 0x58, with R13 = 0 Call chain enters UnityEngine.Animator::Update_Injected with zero delta time: Animator.Update(0). The final log messages in both cases concern remote avatar limb initialization. No Udon runtime exception was recorded during the failed entry. The specific Animator, avatar or world object responsible has NOT been identified. The last avatar mentioned in the log is not a confirmed cause. ENVIRONMENT VRChat 2026.3.3p2-1921-15c4a824b2-Release Windows 11, build 26200 Steam installation, Direct3D 11 NVIDIA GeForce RTX 3060 Ti, 8 GB VRAM 32 GB RAM Crash dump, full logs and detailed analysis were submitted privately through support ticket #745343. Could you investigate the native Animator.Update(0) crash path and advise what additional diagnostic information would help identify the trigger?

Action Menu > Tools (keep the menu open) Toggle Face Mirror with F4 Expected behaviour: Current state of Face Mirror being reflected correctly and immediately. Current behaviour: Changing Face Mirror state with the keybind doesn't update it in the Action Menu.

Happened upon launch

Regardless of which avatar you attempt to load (only personal uploaded should work) it will instantly reject the request to download and refuse to load from cache if already in cache. Tried clearing cache and downloading from regular live client (which works fine in live). Optional cleaning for test Clear content cache in live client. Restart live client and allow avatars you've uploaded to load. Steps Launch Build & Test by any means into a test world. Instantly shows error robot and presents the attached error for any attempts at loading avatars.

Reproduction. Open Vrchat while using hand tracking. Open quick menu. Description. Right hand not interacting with the quick menu while using hand tracking. Can't interact with people's bubbles either, with just the right hand. Video Attached. Category: Menu/UI Frequency: Always Side note* This is not game breaking, but I'm sure it's not intended. And a bit annoying as someone who uses hand tracking every day.

In VRChat Avatar SDK 3.10.X and below, it is possible to run a simple exploit that bypasses the Poor rank. What does bypassing Poor mean? Normally, as soon as an avatar has one light source, the avatar is classified as Poor. If a user blocks Poor and Very Poor avatars, that avatar should be blocked. However, with this exploit, the SDK can be tricked into reporting the avatar as Good. Symptoms The avatar shows the Good rank in the Test SDK build The avatar shows the Poor rank once uploaded as a normal avatar The Poor avatar still behaves as Good even when labeled as Poor Steps to reproduce Create a Good avatar Add a Particle System to the avatar In the Particle System, scroll down to Lights Create a Point Light in the scene but outside the avatar Create a prefab of the Point Light Insert the Point Light prefab into the Light slot inside the Particle System Increase the light count to 20 or even 1000 Upload the avatar as Test using Build and Test Result The Test SDK avatar is shown as Good Upload the avatar normally Result The avatar is shown as Poor and reports only one light source Now the absurd part Use the Poor avatar that was just uploaded Ask a second player to block Very Poor and Poor avatars Result The avatar is still visible even with Poor and Very Poor avatars blocked Affected Platforms: PC, PCVR, Quest How Curcial is this Exploit: I did a test in a private black cat instance. 25 Players did block my avatar. I was able to crash 18 persons by using this. Video showcasing the issue with the test avatar; https://files.catbox.moe/nv2h2c.mp4 Expected Result: VRChat should count every single Light Source no matter if its inside a particle system or outside a particle system. it should also be blocked on Quest (like it does on mobile)

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

Physbones will jitter when Immobile Type is set to the "World" option while the Immobile strength is set to a high value (Especially when set to the maximum of 1). They will jitter even when the player is standing completely still, and the issue appears to get worse the further a player is away from the origin point (X=0 Z=0) of the world, though the issue is still present regardless of where the player is located. The issue is persistent on PC (both desktop and PCVR) and is present on the Quest platform too.