Bug Reports

There has been a major avatar animator desync issue in large instances (60+ players). It seems quite random with who it affects, some players are not desynced (their animations/toggles/facetracking show just fine) and some players are in their default upload state. To reproduce, join a very large instance and you'll notice several players in their default upload state, by asking around or recognizing friends' default avatar. Players that are on the live build 1865, open-beta, and Unity 6 branch can see other players desynced AND they themselves can be affected by the desync.

I was trying to do the following setup (indicated in the image) to be able to create a pointer to select items in a menu. I noticed that the pointer (in the test case, a contact sender type Box) doesn't calculate the interaction between the cursor and the contact receiver correctly. In my tests, it seems to creates a bonding box around the cursor and calculates based on that, thus showing a proximity that is not consistent with the intersection of the sender with the receiver. This bug affects all currently available versions: public, open beta, Unity-6 and SDK here an an avatar with a example of the bug: https://vrchat.com/home/avatar/avtr_175e72f7-ca81-403b-89be-fa2ad211180c and here the link for a VRCfury prefab with the setup: https://drive.google.com/file/d/1Y-CZVjsg7-ydc9afXYO6-Ee5HmeCoMf4/view?usp=sharing *Note: If you change the cursor type from box to Capsule, the receiver stops working completely, this is also not expected behavior.

## Overview The parameters of a User preset configured on an AudioReverbZone stop being applied correctly starting from the 2nd time (and onward) the user joins the world. The AudioReverbZone itself is active and reverb is applied, but the reverb sounds as if different parameters are being used than the ones originally configured. ## Steps to Reproduce Prepare a world with an AudioReverbZone component that has arbitrary parameters set via a User preset. Join the world (1st time) → Reverb is applied correctly, matching the configured settings. Leave the world once, then join the same world again (2nd time onward). The AudioReverbZone is active and reverb is applied, but the sound is as if different parameters are being used than the ones originally configured. A world for reproducing the above steps has been prepared. https://vrchat.com/home/launch?worldId=wrld_4ced52a1-695c-42c6-9e01-966acc4ea11e An AudioReverbZone and an AudioSource are set up around the green cube in the world mentioned above. When you use the white cube, it will overwrite the parameters of the AudioReverbZone that were set during the world upload. ## Expected Behavior Even after rejoining, reverb should be applied with the parameter values matching the User preset configured on the AudioReverbZone. ## Workaround After joining, if Udon re-overwrites the originally configured parameters, they return to the correct values at that moment. However, if you rejoin after that, the same issue recurs. The issue was not resolved unless the VRChat content cache was cleared. ## 概要 AudioReverbZoneに設定したUserプリセットのパラメータが、ワールドへの2回目以降のJoinから正しく適用されなくなります。 Reverb Zone自体は有効でリバーブはかかっていますが、本来設定した値とは異なるパラメータのリバーブがかかってしまいます。 ## 再現手順 AudioReverbZoneコンポーネントにUserプリセットで任意のパラメータを設定した物を配置したワールドを用意する ワールドにJoinする(1回目)→ 設定通りのリバーブが正常にかかっている 一度ワールドを離れ、再度同じワールドにJoinする(2回目以降) AudioReverbZoneは有効でリバーブはかかっているが、本来設定した値とは異なるパラメータの音になっている 上記の再現手順を実施するためのワールドを用意しました。 https://vrchat.com/home/launch?worldId=wrld_4ced52a1-695c-42c6-9e01-966acc4ea11e 上記ワールドの緑のCube周辺にAudioReverbZoneとAudioSourceが設定されています。 白のCubeをUseすると、ワールドアップロード時に設定してあったAudioReverbZoneのパラメータに上書きします。 ## 期待される動作 Joinし直しても、AudioReverbZoneに設定したUserプリセットの値通りのパラメータでリバーブが適用されること。 ## 回避策 Join後、Udonで元々設定していたパラメータを再度上書きすると、その場では正常な値に戻ります。 しかし、その状態で再度Joinし直すと、同じ症状が再発します。 VRChatのコンテンツキャッシュを削除しない限り、症状は改善しませんでした。

Since around June 17, 2026, the Visits counts for VRChat worlds may have been increasing abnormally. Based on posts from multiple world creators and external tracking services, this does not appear to be limited to a specific world. Several unrelated worlds seem to have shown a significant change in their Visits increases around the same time. For example, some worlds appear to have roughly doubled their daily Visits increases after around June 17. There have also been reports of unexplained Visits increases in worlds that normally receive very few visitors, worlds intended for small groups or personal use, and newly uploaded worlds where the creator only entered for testing or to take screenshots. At the same time, in some cases there does not appear to be a significant change in Favorites increases, social media promotion, or other factors that would reasonably explain the increase. This makes it difficult to explain the situation as simply an increase in popularity or traffic. Could you please check the following? Whether the Visits aggregation logic or counting conditions changed around June 17, 2026 If there was a change, whether it was an intentional specification change Whether there is currently an issue with how Visits are being counted If possible, whether creators can be informed about any specification changes and their impact Visits are an important metric for world creators when analyzing post-release performance, the impact of updates, promotion results, and comparisons between worlds. If Visits are currently being counted using a different standard than before, it becomes difficult to compare them with past data, which has a significant impact on creator-side analysis. For reports related to this issue, please see my X post below and the quote reposts on that post. https://x.com/oe_tw/status/2070338873633444118

On my Galaxy S25 Ultra, running Android 16, many images throughout the client (World Pictures, Banner Images at the tops of World Playlists, loading screen tooltip images, etc.) look very wrong (pictures attached). Interestingly, though, the world image that appears on the "Initializing World" screen, looks completely fine. World Images also consistently look extremely noisy on PC (basically like this, just not yellow), but I'd imagine that's a separate issue.

Following up on this completed Canny and developer update from last month , the issue isn't fully resolved. Group members with the "Create Members-Only Group Instances" permission do not see the ability to make group public instances in the VRChat client, but they can still make group public instances and invite themselves by manually crafting a public instance link in the browser. Current mitigation until VRChat resolves the issue: Don't allow group members to open Group instances. Enabling Group+ instance creation does not allow the exploit. The last exploit was left open for over a year. I hope this one won't see the same treatment. I'd really like to allow our group members to create their own group instances without the risk of having unauthorized public instances opened. Thank you to our community member Joakorex for bringing this to our attention. <3

When equiping the "Vketchan 01 Beret", the default placement for the Head bone is placed way too high.

When multiple clients call SetOwner on the same object at the same time, a persistent desync can result, which can only be resolved by taking ownership by a third client. I have a simple repro world here: https://vrchat.com/home/world/wrld_9ee8c772-e157-416a-acc4-513615d36776 Source code: https://gist.github.com/bdunderscore/028b06692dab73ffc8732204f2108f14 When the cube is turned on (blue), the local client will attempt to take ownership every 0.2-0.4 seconds. To repro: Connect with three or more clients. On two of the non-master clients, click the cube. Wait until the Owner: indicator settles down into a desynced state. Then turn the cube back off. Observe that it remains desynced. I tested this on the unity 6 beta, but this repro was based on a bug report for a more complex system on live as well, so I expect the bug is present on both.

Since the update to Build 1864, whenever I play in certain worlds, Easy Anti-Cheat invariably displays a “Disconnected” error after about one minute, forcing me back to the Home World and preventing me from continuing to play. I have confirmed that this error occurs in the following worlds: ・Rhapsody ep. 1 - Grave (wrld_b999a5e6-5ea9-4120-bd88-f8db385bbca6) ・Rhapsody ep. 2 - Scherzando (wrld_241bfaf5-8c8e-4805-8c33-8f6087e65eaf) In these worlds, teleporting to almost any area—excluding Mirage Cape and the starting area—will invariably trigger an EAC error within about one minute. This issue occurs regardless of whether you’re in desktop mode or VR mode, and numerous users have reported the same symptoms.

When Enable Spatialization is ticked, if a player causes an audiosource to call audiosource.play () and then moves out of the range of the audiosource and the audiosource is played again, the player will hear the audio for a split second. The audio will then "move" towards its actual location with each successive play of the audiosource until it cannot be heard, as intended. To reproduce this: create an audio source and add an audioClip in unity, add the vrc spatial audio source component check "Enable Spatialization" Set Spatial Blend to 3D ( and ensure its not global, eg. a custom rolloff) Add a script that will play the audio source such as: using UdonSharp; using UnityEngine; using VRC.SDKBase; using VRC.Udon; public class audiotester : UdonSharpBehaviour { [SerializeField] private AudioSource audioSource private void Update() { if (Input.GetKeyDown(KeyCode.F)) audioSource.Play (); } } Wire up the audio source game object with a game object that contains the script in the inspector Put the audiosource game object at 0,0,0 position Publish the World In the world in vrchat press "F" once to hear the audio Move out of range of the audio source Press "F" again The start of the audiosource will play at volume for a second, and be heard outside of its defined range