Quest 3S stuck on PTC/Beta firmware - cannot leave, ADB broken, device missing from account
Hi everyone, tagging @MetaQuestSupport because I really need help. My Quest 3S is permanently stuck on the Beta (PTC) firmware and I can't get out of it no matter what I try. What I've tried: Toggled PTC OFF in the Meta Horizon app multiple times Factory reset multiple times (boot menu + Meta website) Manual ADB sideload of stable firmware (completes successfully but headset always boots back into beta) ADB commands to disable OTA updates The core issue: The bootloader always boots from the beta partition regardless of what I sideload. It seems like a server-side PTC lock that only Meta can remove from the backend. Additional problem: After multiple factory resets, the Quest 3S no longer appears in my account's device list on the Meta website, even though the headset is still logged into my account. What I need: Manual removal from the PTC program on the backend Re-linking of the device to my account The beta firmware is also causing hand tracking crashes and USB debugging (ADB) to malfunction. Thank you so much, any help is appreciated! 🙏83Views0likes1CommentFeature Request / UX Discussion: Separate Immersive App Control UI From 2D Apps
``` I’d like to discuss an issue with how immersive apps interact with running 2D apps when switching contexts using the Meta button on Quest. The problem is not the immersive app itself, but the 2D control window that appears for immersive apps (the window with Resume, Close, and other controls). When this window is shown, it is treated like a normal 2D app, and its appearance often causes currently running 2D apps to be minimized, closed, or refreshed. This behavior makes multitasking unreliable and forces users into specific app-launch sequences just to avoid losing state in their 2D apps. Proposed Behavior Change The idea is that the immersive app control window should not behave like a standard 2D app and should not interfere with other running 2D apps. Specifically: - Showing the immersive app’s control window should not minimize, close, or replace existing 2D app windows - The immersive app control UI should exist in a separate system layer, not the same layer as user-launched 2D apps - Running 2D apps should remain exactly as they are when the immersive app control UI appears - Access to Resume, Close, and related immersive controls should be possible without disrupting active 2D workflows - Ideally, immersive app controls could be accessed via a dedicated icon, overlay, or system-level panel rather than a standard 2D window In short: Viewing or interacting with immersive app controls should not be treated as “launching a 2D app.” Why This Matters - Prevents active 2D apps from being kicked out or refreshed - Makes switching between immersive and 2D contexts predictable - Improves productivity and multitasking - Reduces frustration caused by forced app restarts - Allows immersive apps to coexist cleanly with 2D workflows This could be implemented as an optional setting or as a revised default behavior for immersive app control UI, without removing any existing functionality. I’m interested to hear if others experience the same issue and whether separating immersive app controls from the 2D app system would improve overall usability. ```40Views0likes1Comment