Bug Reports

Sit down in VRCStation Use Udon to change VRCStation’s transform Your torso won’t rotate with you and will be dragged along (on desktop, your hands will be too!)

Steps: While in PC VR, select a user, and click "gift vrchat+" then with the 1 month option selected, press "purchase gift sub for XXX" Issue: After clicking this it often just spins, and nothing happens. No error messages or feedback on whether it failed or succeeded. Other: VRC is probably losing a lot of potential money from this. This whole process has a lot of unnecessary friction, and could be made better. A simple suggestion is to allow purchasing of VRC+ with VRChat credits to cut out all the third party stuff (steam, paypal, etc) so it can truly be a "1 button press" thing. It's hard to debug since I don't want to hammer at an issue that costs real money, so I don't have more useful info. Sometimes it does succeed and works as intended, but that's rare.

To reproduce, separate the eye look values into left and right, then only set rotation values for one of the eye bones and keep the other eye bone at 0 rotations for all states The other eye bone will copy the Left and Right rotation values of the eye bone that had them set The up and down rotation respects the split values This is a problem for stylized avatars that need different L/R values for looking left and right, and overall unexpected behavior https://imgur.com/a/0inTA8C I tried on two different avatars, one with 0 values on the left eye bone and the other with 0 values on the right eye bone I'm not sure if the problem is on any platforms besides PC, I assume it probably is It happens with Selfie Expression as well

I was in an instance where $650 worth of vrchat gifts were dropped and I did not recieve the pride fan. It's possible that this happened because my account ID is the old style (IcFlB5xJud) which has broken events in the past like the halloween candy event. See attatched evidence.

After the most recent update (2026.2.2 Build 1853), many members of my community are unable to join certain worlds, myself included. We attempt to join the world, it loads to 100%, then kicks us back to our home worlds. Preloading the world also stops at around 99%, then just hangs. I've confirmed this issue occurs on Desktop and PCVR. I haven't experienced it on mobile yet, and Quest users seem to be okay, but the issue I briefly mention below happened on Android mobile on a Samsung Galaxy S25 Ultra (again, only after updating to the most recent build). I've attached a log file that a community member provided me, and a couple images showcasing: The portion of my own log that I assume to be most relevant A screenshot from the mobile version of the new update that leads me to assume this issue may be related to the new image compressor that was implemented in the most recent update (though these could be two unrelated issues, I just figured I'd include it in case it's relevant).

I run an event that fills up pretty quickly once we announce that guest doors are open. We open the the instance as a group instance with instance queue enabled. After we get all of the staff into the world for the event, we announce on discord and in group pings that the instance is now open for guests to join. Guests should be joining and starting up a queue at the announced time. What they can currently do is use the "Show Go Button on Load" setting to preload the world and reserve their spot in the instance. We can't tell what guests are doing this because they don't load into the world, we have no idea who hass connected early. They simply join the world with everyone else once the ping has gone out. You can test this easily with 2 other people. 1) Create a group instance with a queue for a world with 2 max slots. Just the two of us works well. 2) Have the instance owner join first and load into the world. 3) Have the person who will use the "Show Go Button on Load" join the instance, but not press the join world button. At this point, the person inside the instance does not see anyone else in the world. The person in the load screen has reserved their spot in the world. 4) Have a third person attempt to join the instance. They will either be placed in queue, or receive an error related to needing to join a queue but it will not place them in a queue. From the perspective of the person inside the instance, no one has joined. The third person cannot join the instance and MAY be able to queue. The second person that is waiting to join can join freely at any time. I do not know how long this instance slot reservation lasts, but it is causing significant issues with group instances with queues.

The Instance Player UI gets overcrowded very easy in a world with a large queue, friends in instance and an active hype train.

When Collision Mode was set to "Hit Players" or "Hit Worlds And Players," my own avatar was hit, but other players' avatars were not. When using "Hit World" or specifying "Pickup" in "Hit Custom Layers," the target was hit correctly. Do other players' avatars also need to be running SDK 3.10.3?

1.open vrchat 2.request a invite 3. Attach a picture 4. The picture is static

Since updating to version 2026.2.2 (Build 1853), avatar performance has decreased significantly for avatars that use a large number of outfit toggles. Before the update, one of my avatars consistently achieved around 60 FPS in Desktop mode. After the update, performance dropped to approximately 35–40 FPS. The performance impact is even more severe in VR. The avatar in question contains 108 Skinned Mesh Renderers and approximately 920,000 polygons in total. However, these outfit parts are only activated when needed. Under normal use, only around 5 Skinned Mesh Renderers are active at any given time, while the rest remain disabled. No changes were made to the avatar between the update and the performance regression. GPU drivers also remained unchanged. The only variable that changed was the VRChat update itself. To investigate the issue, I performed several tests by removing different avatar features. The most significant finding was that performance only returned to normal when inactive Skinned Mesh Renderers were completely deleted from the avatar, even though their GameObjects were already disabled. After removing the inactive renderers, performance immediately returned to around 60 FPS. This suggests that disabled Skinned Mesh Renderers may now be incurring a substantial performance cost, as if they are still being processed despite being inactive. Another important observation is that the performance drop only affects the player currently using the avatar. I tested this with another user. When they equipped the same avatar and I observed them, I experienced no noticeable performance impact. However, the user wearing the avatar immediately experienced the same severe FPS drop. We repeated this test with several other avatars that contain a large number of outfit toggles implemented through Skinned Mesh Renderers and observed similar behavior. Based on these tests, it appears that a change introduced in update 2026.2.2 may have affected how disabled Skinned Mesh Renderers are handled on the local player. The resulting performance degradation is substantial and affects multiple avatars that previously performed as expected. Please investigate any changes related to Skinned Mesh Renderer processing in this update, as this appears to be a significant performance regression.