Bug Reports

Description On mobile, the tutorial that appears (specifically the one that says “Tap someone to see more information and options. Give it a try!”) doesn’t disappear from the screen once tapping on someone as instructed. This leads to a large majority of the screen being obscured. Reproduction Steps Be on iOS and in an instance with more than one person, tap on them as instructed by the tutorial. It will not disappear no matter what. Details Category: User Interface Frequency: Always --- platform: iOSMobile (platform: iOS - Mobile, store: TestFlight, headset: None) rawPlatform: IPhonePlayer clientVersion: 2026.3.10000 unityVersion: 2022.3.22f2-DWR In-Client Report --- Log file: output_log_2026-08-14_22-32-15.txt

Description On initial opening of friend's list, I am able to see which friends are in friends or friends+ instances. Joining is normal/functional as usual. However, after leaving the instance and rechecking the friend's list, the same friends are now listed as "in private instance" with a green light despite no instance change. Reproduction Steps Reproducible by joining friends/friends+, leaving, and checking friends list to see it is now changed to "private instance". Untested with friends in public instances. Restarting VRChat fixes it, but issue reappears when reproduction steps performed. Request invite used to join instance after bug appears. Details Category: User Interface Frequency: Often --- platform: PC (platform: Windows, store: Steam, headset: None) rawPlatform: WindowsPlayer clientVersion: 2026.3.1-1886-a268441585-Release unityVersion: 2022.3.22f2-DWR In-Client Report --- Log file: output_log_2026-08-17_17-00-52.txt

Description mmyy kkeeyybbooaarrdd kkeeppss ttyyppiinngg ddoouubbllee lleetttteerrss eevveenn wwhheenn iimm pprreessssiinn ttwwiiccee pplleeaassee ffiixx tthhiiss!! ii uussee hhaanndd ttrraacckkiinngg pplleeaassee ffiixx tthhiiss iittss vveerryy aannnnooyyiinngg Reproduction Steps iitt hhaappppeenndd rraannddoommllyy,, pplleeaassee hheellpp ii ddoonn''tt kknnooww wwhhyy tthhiiss hhaappppeenndd iitt ccaammee oouutt rraannddoommllyy.. nnoobbooddyy iiss ttoo bbllaammee ffoorr tyhhiiss oonnllyy tttthhee kkeeyybbooaarrdd.. Details Category: Other Frequency: Always --- platform: Quest (platform: Android - Quest, store: Oculus, headset: Oculus Quest 2) rawPlatform: Android clientVersion: 2026.3.2-1901-4a7d603ee0-Release unityVersion: 2022.3.22f2-DWR In-Client Report --- Log file: output_log_2026-09-01_19-14-43.txt

The documentation for VRC constrains implies you can edit a constraint's sources at runtime. The only runtime limitations given in the documentation is that the target transform cannot be changed, that "changing a transform reference at runtime can cause performance issues." In my scene I have a rode-shaped VRC pickup with a child transform representing the tip. Separate from it I have a sphere with a VRCPositionConstraint and the below script attached. The targetSource serialized field points to the pickup's tip transform. ```c# public class TestConstraintRuntime : UdonSharpBehaviour { [SerializeField] Transform targetSource; private void Start() { VRCPositionConstraint constraint = GetComponent<VRCPositionConstraint>(); constraint.Sources.Add(new VRCConstraintSource(targetSource, 1f)); Debug.Log($"Sources count: {constraint.Sources.Count}"); constraint.IsActive = true; constraint.ApplyConfigurationChanges(); } }``` When the constraint's source is set to the tip in inspector, the constraint performs as expected. But when it is not set in the inspect and assignment is left to the script at runtime, nothing happens. I also attempted to change at runtime the weight an inspector set constraint source using the method specified in the documentation (pulling out a source; setting the weight field; and then returning the source), but that also failed to have any impact. For sanity I tried to perform the same logic with a Unity constraint and that worked without issue. Either this is a bug or the documentation needs to clarify that these changes cannot happen at runtime.

Desktop-only install. Window is black from startup, audio plays (login music). Never get a visible login UI. PC: Beelink SER9 (AZW), AMD Ryzen 7 255 with Radeon 780M, 32 GB RAM, Windows 11 24H2 (10.0.26100) Client: Steam, first install. Reproduced on live and Open Beta. Both report build 2026.3.2-1901-4a7d603ee0-Release, Unity 2022.3.22f2-DWR. Tried: --no-vr, -force-d3d11, -force-d3d12, windowed, prefs/registry wipe, file verify. GPU is correctly AMD Radeon 780M Graphics in the log. Log pattern every launch: Activating login loading screen Created Stacked Camera : Cam_InternalUI NullReferenceException on the camera stack Manual login failed. Will prompt again. Output logs attached. Not for me, My friend is having issues even booting up the game, here are the logs for everything

This is a bug that originated during the beta phase—which introduced the current nameplate and UI designs—and it has persisted into the public/live version. It is also currently present in the BETA and UNITY-6 versions. The error occurs following packet loss, a lag spike, or a momentary disconnection. VRChat then displays one of the following messages: -VRChat is not responding -VRChat is time out -VRChat is disconnected However, upon attempting to reconnect, the application gets stuck on an infinite "Connecting" screen and remains that way until VRChat is completely restarted. Through testing, I noticed that this error occurs when wearing a "Very Poor" avatar. It does not happen when using avatars rated "Excellent" through "Poor." Here is what I have ALREADY TRIED to fix it: -Completely uninstalling and reinstalling VRChat like new -Uninstalling SteamVR -Clearing the entire VRChat cache -Updating network adapter drivers -Clearing the DNS cache -Factory resetting my modem/ONT (provided by my ISP) Internet speed 500 Mbps Nothing in BETA version. The error persists when wearing a "Very Poor" avatar. Consequently, I recorded a video demonstrating how to reproduce the issue, which I have attached to this post. https://drive.google.com/drive/folders/19J3GcJulC83eIxAWFfAs74w0CerTZQfL?usp=sharing https://drive.google.com/file/d/16hOCxMhEpSlXbdwl0FRcWSAUB2bz4tAg/view?usp=sharing In the video, I used two avatars: one "Excellent" and one "Very Poor." I simulated an internet disconnection by simply unplugging my LAN cable for 15–20 seconds to trigger the "time out" message. I am also attaching the output_log files from each session shown in the video: Avatar_Excellent_output_log_2026-08-14_01-03-37 – For the optimized avatar. Avatar_VeryPoor_output_log_2026-08-14_01-23-05 – For the "Very Poor" avatar, where the error/bug preventing reconnection occurs. I would also like to highlight the following lines from the log file where the error occurs: 1.- Error - [NetworkTransport] Failed to raise deferred operation of type 13. 2.- Error - SocketWebTcp.CloseCallback(). Going to disconnect. Server: wss:// ns.photonengine.io:443/ Error: 1005 Reason: 3.- System.Exception: Failed to raise deferred operation of type 13. at ÎÌÍÏÍÍÍÍÍÎÌÍÎÍÌÎÌÍÎÎÍÏÎ+ÏÌÍÏÏÎÌÏÍÍÏÌÌÎÍÌÏÌÎÌÎÏÌ.ÍÌÌÌÎÎÌÍÏÌÍÎÎÎÍÏÌÍÎÍÍÌÍ (System.Predicate`1[T] ÏÌÏÎÏÏÏÎÎÌÏÎÌÌÎÎÏÌÏÎÌÌÏ) [0x00000] in <00000000000000000000000000000000>:0 These lines appear repeatedly when the error occurs, indicating that the session will not reconnect. I hope you can help resolve this error, as it is very frustrating to have to completely restart VRChat whenever this momentary disconnection happens. The information from my PC is located in the .tex files.

Yesterday, I experienced this twice, and my friend experienced it every time when switching instances. VRChat simply crashed without showing an error or even reaching the "initialize" stage. This has happened occasionally before, but I suspect the frequency has increased recently. ja: [1886] インスタンス移動時にVRChatが落ちる頻度が上がった 昨日私は2回、フレンドは毎回、インスタンス移動時initializeが出るまでも無くVRChatがエラーもなく落ちる事象が発生しています。 以前も時々あった現象ですが頻度が上がった疑惑があります。

Description: Users with the correct group permissions are sometimes unable to invite certain group members into an instance, despite meeting all requirements for those members to join. The problem is intermittent and does not affect all users equally. --- Steps to Reproduce: Create or join a group-only instance. Ensure you have full invite permissions for your group. Attempt to invite a member who meets all entry requirements. Observe whether the invite button is faded or not. --- Expected Behavior: * All group members who meet instance requirements can be invited successfully every time. --- Actual Behavior: * Some group members cannot be invited intermittently, even when permissions and requirements are satisfied. * The issue does not consistently affect the same subset of members. -- In the image provided below, I as the group owner was unable to invite the group member shown below to an instance I created. This issue appears to affect group-only instances only.

When I go settings and into the debug section to empty my content cache. After restarting my game my cache refuses to empty!

It seems that certain particle buffer system's may be causing crashes for the local user invoking "Object reference not set to an instance of an object" within the logs. I cannot attach the text document, but I have linked the log via dropbox here: ( https://www.dropbox.com/scl/fi/dsxksffc6uvahr9mk9367/Crash_Log.txt?rlkey=dyl42y5yawepbwnhkhg4mjc78&dl=0 ) Avatar id that has the system: avtr_d405638e-7f88-42f3-9b03-f0a0636ae86c The avi is not public, but to replicate: 1) Load avatar 2) Enable block building 3) Right thumbs up 4) Highlight and select a block with 'Right Fist' 5) Either close the menu by walking away from it or hitting the X in the top right with 'Right Fist' 6) Point hand anywhere and hit 'Right Fingerpoint' 7) Hooray! You crash. Attached is an image of the particle system in question. Each object below "BlockBuffer" is a sub-emitter that has emission toggled on and off dynamically and subsequently placed by the "Block Buffer". I have tested removing different sub-emitters at random and it seems rather arbitrary to when it suddenly decides to work. Perhaps it's more tied to the amount of them? Do note that this system works without crashes flawlessly on both the live build as well as the open-beta!