Bug Reports

Happened upon launch

When playing VRChat for several hours, sometimes even just over an hour, friends in the menu stop updating. This includes statuses, locations, and even friend requests. I regularly have to use the website to accept friend requests and need to restart my client multiple times a day to be able to join others. This may affect other types of updates as well such as groups. I'm using Linux and a few other Linux friends report the same issue, however there are a few Windows users who also experience this. Our best guess is that the API websocket doesn't properly reconnect leaving the client in a stale state.

Since the 2026.2.3 Stable update, I have noticed that the Steady Cam POV output produces a different smoothing feel compared to pre-2026.2.3 builds. I primarily use Steady Cam as an external POV camera feed for recording/streaming VRChat events, especially clubs and other event spaces. Enabling it does not significantly change my own in-headset experience, but it changes the camera output that viewers see when watching a recording or stream. This is where the issue becomes noticeable. With the new Build, the recorded POV feed feels less smoothed and more aggressive than before: quick left/right head turns feel snappier on screen; the apparent rotation speed during quick turns seems higher; small high-frequency head movement/hitter is more visible in the footage; subtle bounces are less filtered and can look uncomfortable to watch; when UI is enabled (mic/face mirror), the UI may snap immediately / not follow the same smoothed motion as before Before 2026.2.3: quick head rotations felt more damped on screen; small head jitter was filtered more effectively; the overall POV feed felt more comfortable for viewers watching a 2D stream/recording Expected behavior: For the same input and settings, Steady Cam’s external camera output should provide similar smoothing/damping behavior as pre-2026.2.3 builds, or at least an option to restore that feel. Small high-frequency movements should be filtered more consistently, and quick head turns should not produce large unfiltered velocity spikes in the recorded/streamed feed. Actual behavior: The external POV output feels less smoothed and more responsive than before. Quick turns are snappier, subtle movement is more visible, and viewers watching a 2D stream/recording are more likely to experience motion sickness compared to pre-2026.2.3 builds. Reproduction Steps: use VRC 2026.3.2p2 Stable [1903] or open-beta [1914] in VR Enable Steady Cam Record your POV output Make quick left/right head rotations make small high-frequceny head bounces/jitters Compare the recorded/streamed footage against pre-2026.2.3 output in the attached video Video link (unlisted): https://www.youtube.com/watch?v=__qZLlO4Ohw The video shows a few comparisons between the current build and pre-2026.2.3 output. It contains on-screen text explaining each comparison, you may need to pause to read it properly. These are not perfect one-to-one recordings because I cannot record new footage for a build that is no longer publicly available, but they should illustrate the difference. Note: This is not mainly about my personal in-headset comfort. It affects the quality/comfort of the external POV camera feed used for recording and streaming. I understand Steady Cam components may have been rewritten, so this seems like a regression in perceived stability/comfort for 2D viewers watching the output. Second Note: My recordings and testing were done on the current Beta build [1914], however because the 2026.2.3 release came out in June, it should affect both open-beta and public branch. Steadycam rewrite quote: https://discord.com/channels/189511567539306508/449386885299830794/1516252086222983279 (pi on vrc discord in open-beta-discussion) tldr: The new Steady Cam implementation [1914] is more likely to cause motion sickness for 2D viewers during snappy head movements, compared to pre-2026.2.3 builds.

Attempting to results of this logged error: 2026.09.17 22:02:31 Error - "Custom fields can not include the following: bio" Open Menu Social Click User Search Search for anything Click Refine Search Check Search by Bio (can uncheck Name) Click update results. Observe error and no results.

1 - Import AVPro video example from VRC's Udon Example SDK 2 - Make improvements, any changes to UdonSyncPlayer script, even in a brand new copy of the script. 3 - Wait. 4 - When the script reverts, try reimporting a backup of the script. 2 days, or 2 months ago, it all gets reverted, and all your work will get erased. I have backups of my progress on changing this script, and all of the improvements and Udon nodes I set in the video player keep reverting back to the example's default no matter what I do. This includes adding a reload button, sync threshold to avoid stuttering for very small sync times, fixing aspect ratio for tall videos, buttons for playing specific videos, a default loop video when the player resets, and a light-dimming feature. All this work got erased and keeps getting reverted. UDON examples SHOULD NOT overwrite my changes. Ever. Now the theater system I painstakingly built in my world which took weeks to develop has been completely gutted, and none of my backups work. Fundamentally, the AVPro video example is completely broken and impossible to fix. This makes me never want to include any Udon examples from VRChat in my project.

Following log spamminig every minute inside output log which shouldn't be happen as PCVR not support selfie expression at the moment. If it log output at very first place, it makes sense but continuously checking every minutes is not make sense and make other log entry difficult to read. Can you stop checking everry minute if it PCVR? Debug - [VRCTrackingSteam] [IK Debug Log] Selfie Expression --- DISABLED - FPS: xxx Quality: 4 Auto Quality: True

When sending warnings to players within an instance after opening up a player profile using the "More Options" menu found through the "Three Dots" menu (next to the reporting button on a user profile); the "Warn User" button doesn't provide a confirmation window to confirm if you would actually want to warn said player. This is inconsistent with the current "Warn User" button found through selecting a user after selecting a user capsule where that one does provide a confirmation box. Solution would be to restore consistency with providing a confirmation box, as the "Kick User" option from the "More Options" menu does provide this confirmation box as expected.

As the title suggests, 1913 supposedly improved framerate with high polling-rate mice. While I've noticed slightly better frames, I've noticed clicks won't even properly register half the times now. I did not have these issues before 1913. I've attempted to use fullscreen, windowed, smaller resolutions, bigger resolutions, and changing my polling rate. I even went as far as to test on VR, which of course does not have this issue.

Groups are sorted ABC...XYZabc...xyz. This means any groups that start with a lower case letter get sorted at the end of your list. It would be more useful to sort them case-insensitive.

Currently in the VRChat SDK when uploading a world, it recommends an image resolution of 1200x900px. However as far as I can tell in practice, VRChat only seems to use 800x600px images, which is 2/3rds the recommended size, resulting in aliasing. So far in my testing this seems to apply to: 1) The website 2) The world image returned by the API 3) The world image as seen in the game client UI (all platforms) 4) Portals dropped in-game (all platforms) While often subtle, it becomes quite noticeable when an image has pixel art, which renders as blurry. The discrepancy between the stated and actual ideal resolutions results in world images looking less sharp than they otherwise could, and without clarification makes it uncertain which resolution to target for design and upload. Attached to this post are 5 images from my world VRCanvas to show the effect of the issue, in the following order (pay particular attention to the sharpness of the text): 1) Uploaded 1200x900 image 2) 1200x900 image as downscaled to 800x600 and displayed by VRChat 3) Uploaded 800x600 image (VRChat displays as-is) 4) Image #1/2 as it appears in a portal 5) Image #3 as it appears in a portal The ideal solution I'm requesting would be to fix the API/client to display in the native recommended resolution of 1200x900, since this is higher quality, and most worlds are already uploaded in this resolution per the VRCSDK's recommendation. If for whatever reason this is undesirable to VRChat (perhaps texture memory or bandwidth reasons?), then the VRCSDK recommendation should be changed to 800x600 to match what's actually the ideal resolution. If this is a texture memory concern, then a third option could be move to a new resolution of 1024x768, since this would still fall within the same power of 2 as 800x600 while still 4:3 aspect ratio and higher resolution.