Bug Reports

When a world becomes full of users, the avatars of later joining users becomes non-functional. No toggles work except locally for the user. So if I were to join such a lobby that was full after waiting in queue, all users that was already in the instance will see me in default state without any toggles enabled or face tracking data showing through until the world user count dips down to about 60. Until then only I can see my own changes to my avatar and FT working as intended but nobody else will. This happened consistantly for over a month in Just B Club during social events I've attended where lobbies are consistantly full. When user count in the world drops down to about 60 then everything starts catching up again and stuff starts working normally for some reason. This issue is not related to any specific avatar, but appear to happen across the users of most avatars in the world who joins late through the queue system.

We've identified a certificate-validation issue affecting VRChat's bundled yt-dlp when resolving HTTPS URLs served through Cloudflare Universal SSL using Let's Encrypt. This does not appear to be an issue with an expired website certificate or an individual user's system configuration. The affected Cloudflare certificate is currently valid: Certificate Authority: Let's Encrypt Certificate type: Cloudflare Universal SSL Expiration: 2026-10-16 Validity period: 3 months Despite this, VRChat's bundled resolver fails with: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: certificate has expired (_ssl.c:1002) Reproducibility The issue reproduces consistently when using VRChat's currently bundled yt-dlp: yt-dlp version: 2026.07.04 The same HTTPS endpoints: * Validate normally in modern browsers * Validate normally through Windows curl.exe / Schannel * Are served using a currently valid Cloudflare Universal SSL certificate * Resolve successfully through alternative/custom yt-dlp integrations * Consistently fail certificate validation through VRChat's bundled yt-dlp This makes the problem appear to be an incompatibility between VRChat's bundled yt-dlp certificate-validation environment and the Let's Encrypt certificate chain currently being served by Cloudflare. Isolating the failure Using VRChat's own yt-dlp.exe, resolving an affected URL normally results in: CERTIFICATE_VERIFY_FAILED certificate has expired Running the exact same request with: --no-check-certificates immediately succeeds and returns the expected media URL. We are not suggesting disabling certificate validation as a workaround. This was used solely as an A/B diagnostic and confirms that certificate verification itself is the point of failure. Why this may have wider impact The affected hostname is not serving a manually configured or unusual certificate. It is using a standard Cloudflare Universal SSL certificate issued by Let's Encrypt. Because Cloudflare deploys Universal SSL certificates across a very large number of domains, this may potentially affect other VRChat video services or websites whose Cloudflare edge certificate is issued through the same or a similar Let's Encrypt chain. This therefore may not be limited to one video provider or one unusual URL configuration. Expected behavior Currently valid HTTPS certificates trusted by standard browsers and operating-system TLS implementations should also validate successfully through VRChat's video resolver. Actual behavior VRChat's bundled yt-dlp reports the Cloudflare-served Let's Encrypt certificate chain as expired and refuses to resolve the URL, despite the certificate itself currently being valid. Temporary workaround Alternative/custom yt-dlp integrations do not appear to exhibit the same issue and can currently resolve the affected URLs. This is not an appropriate long-term solution for world authors or normal users, but it may provide a temporary workaround for users already running such tools. Reproduction URLs We would prefer not to publish affected production endpoints publicly. We have confirmed URLs that reproduce the issue consistently and can provide them, along with certificate details and our testing results, privately to VRChat staff. VRChat staff are welcome to contact us and we'll provide the affected URLs and full reproduction information privately.

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.

Unsure if it also shows up like this in an actual profile since I'm not interested in paying $10 for this but the preview looks wrong.

When Steadycam is enabled if you open the Stream Camera it will reset to disabled after closing the stream camera. I'm unsure if this is a bug or an intended feature, but if so I'd like to request a setting at least to change it back. As a VRChat streamer I adopted this system so I can comfortably stream first-person adventures to my viewers and switch to camera view to talk with chat on the fly. Now I'd have to re-enable steadycam every time I want to open the stream camera. Example posted on my twitter https://x.com/ProjektKisu/status/2087314815169810543?s=20

1.) Use full body tracking (7 point used in this example: chest, hip, Lfoot, Rfoot) 2.) Set "FBT Locomotion Animations" to off. 3.) Set "FBT Spine Mode" to "Lock Head" 4.) Move around with the joystick. 5.) Notice your avatar and hands do not shift around as you start and stop movement, this is expected behavior. 5.) Change FBT Spine Mode to "Lock Hips" 6.) Move around with joystick again. Observed Behavior: The entire avatar shifts whenever you start and stop moving, including your hands, head, and hips. Expected Behavior: Tracking should feel just as smooth as Lock Head mode when you start and stop moving.

The Android platform icon is so small on the new nameplates that at most distances I cannot make it out. From far away it looks like a small white dot, then closer a donut, then once you’re on top of the person you can maybe make out the android-shaped-hole in the donut. This icon needs to be much larger, at least as large vertically as the text next to it, if not larger. And it should be green, like the android logo is everywhere else in the UI. A color would likely help being able to make it out from any distance. My biggest complaint about the previous phone/tablet icon from earlier iterations was the minuscule size, and this new icon is no better.

This is considered inconsistent behavior since the "View on Website" button on user profiles asks "This link will open in a browser on your device. Are you sure you want to continue?"

Description friends on green and blue statuses are not joinable even when thay are in a friends plus instances. Reproduction Steps it happens randomly after being on for a bit Details Category: User Interface Frequency: Sometimes --- platform: Quest (platform: Android - Quest, store: Oculus, headset: None) rawPlatform: Android clientVersion: 2026.3.1-1886-a268441585-Release unityVersion: 2022.3.22f2-DWR In-Client Report --- Log file: output_log_2026-08-13_20-46-48.txt