“file uri scheme”

I can already tell you, nothing works for me anymore. I updated to macOS 26.4. This morning, it updated Xcode to 26.4 as well. As a result, I had to reinstall Codex, which I did. I logged in, and now nothing works at all. I can submit a request in the chat, sometimes I get a short response, and then it starts thinking about something and never stops. I think it is amazing what kind of unfinished mess Apple is delivering once again. This is absolutely unbelievable. I am furious that such a broken system is being provided to us developers. It would be the easiest thing for Apple to simply test Codex. If they are not even providing us with the latest Codex versions and instead releasing outdated versions with their Xcode, it is outrageous that we are given something so completely unfinished and nonfunctional. With macOS 26.3 and Xcode 26.3, I was at least able to program perfectly fine with Codex and developed several apps. Now I wake up in the morning, want to continue working on my apps, and great job, Apple,

I have hit this exact crash pattern in my own ScreenCaptureKit audio capture pipeline. The EXC_BAD_ACCESS in swift_getErrorValue happens because the error object passed to didStopWithError is being deallocated before the delegate method can access it — it is a race condition in the XPC boundary between replayd and your process. The root cause in my case was that the SCStream object was being deallocated (or stopCapture was called) while a pending error was being delivered across the XPC connection. The error object lives in replayd's address space and gets bridged to your process, but if the stream tears down mid-delivery, you get a dangling pointer. Keep a strong reference to the SCStream instance beyond the point where you call stopCapture. Do not nil it out immediately. In your stream delegate, wrap the didStopWithError handler in a DispatchQueue.main.async to ensure the error is fully materialized before you access it: func stream(_ stream: SCStream, didStopWithError error: Error) { let errorDesc = String

OK by this: I tried deleting iOS 18 runtime via Xcode Settings > Components, and even removed iOS 26 runtime then re-downloaded it. But the iOS 18 runtime keeps auto-reappearing right after! I also ran sudo rm -rf against the iOS 18 asset folder, and it just throws a permission error—totally useless. I checked the Info.plist under /System/Library/AssetsV2/com_apple_MobileAsset_iOSSimulatorRuntime/cc1f035290d244fca4f74d9d243fcd02d2876c27.asset/ and confirmed this folder is exactly the orphaned iOS 18.0 simulator runtime. I’m trying to delete this specific cc1f035290d244fca4f74d9d243fcd02d2876c27.asset folder but hit a wall with system permissions. I found this exact issue is already being discussed in the Apple Developer Forum thread here: Orphaned 9GB Simulator Runtime in /System/Library/AssetsV2 - Cannot Delete (SIP protected). It’s clearly a bug on Apple’s side with MobileAsset lifecycle management—these large orphaned simulator runtime assets get stuck in SIP-protected system directories, and Xcode/simc

What you'll find is that there are two clients— yours and a (presumably unrelated) 3rd party client. The other ES client is basically a 3rd party logger that's not active. Ours does some auth work, but we're fairly certain in this case it's just monitoring to do reporting and follow-up scans. Do you know exactly what kicked off your helper process? Both in terms of the triggering event and the target file? No. At the time, the system had been idle for 2 hours. In this case, we do observe a system update being staged in the background, but not in all other instances. I suspect it was a FILE_NOTIFY_CLOSE. It would be insightful to know if APFS triggers that or related ES events when decompressing a file. A big part of the problem here is that the data we're looking at is being collected LONG (2+ days) after the problem itself actually occurred, which means we don't REALLY know EXACTLY what happened. I will submit unified logs that cover the period in question, but your point remains. That ES c

So it appears to be the same failure we are talking about here: https://developer.apple.com/forums/thread/814076 I just updated that thread, but the bug described there (FB21805212) was fixed in macOS 26.4. Also, to be clear, the bug was specifically in smb, NOT copyfile itself. However... It has data. I can read the filenames when I view it as 'plain text’. The Resource fork is less than 300 bytes, but that is enough for it to cause copyfile to fail. The total file size is ~12kb. That doesn't sound like the bug above. The bug above was caused by the SMBClient incorrectly accounting for large xattr size, which then caused the copy to fail. I don't think it would have happened with small xattrs (certainly not 300 bytes). FYI, the Finder (and other copy engines) work because they're using the ..namedfork accessor, when it ends up going through a totally different code path in smb. Interestingly, .DS_Store causing problems with copying is infamous enough to have a mention on Wikipedia: Yes, but I think

FYI, FB21805212 should be fixed as of macOS 26.4. If you're experience this or similar failure on macOS 26.4 or later, please files a new bug and start a new forum thread with any questions. __ Kevin Elliott DTS Engineer, CoreOS/Hardware

Thank you for sharing your post. I understand that it can be frustrating, especially when the job is impacting your daily routine. I am eager to assist you in any way I can. I have a potential idea, but I would like to request a bug filing for further investigation. Typically, authentication tokens expire after a few hours. In a stable build, Xcode silently uses a “refresh token” to obtain a new session in the background. Consequently, the system may be terminating your session when the initial token expires. This is an issue that requires immediate attention. However, I am only speculating about the cause. Given that this issue is occurring across two separate computers and began specifically in beta 3, it is highly probable that the problem lies within the beta itself rather than a misconfiguration on your end. Instead of simply signing out and signing back in, I recommend completely deleting the integration from Xcode. Navigate to Xcode > Settings > Accounts (or the specific Claude Agent set

Thank you, I will file a bug report. For anyone else that finds this, the scrollbar: always shows on my Mac Mini (mouse and keyboard only) does not show on my Macbook Air (trackpad) automatically shows when I connect a bluetooth mouse to the Macbook Air, but still does not allow mouse interaction. When I turn off the bluetooth mouse, the scrollbar disappeared. The trackpad allows for scrolling the chart with 2-finger swipe gestures, with or without the bluetooth mouse connected.

Our engineering teams need to investigate this issue, as resolution may involve changes to Apple's software. Please file a bug report, include a small Xcode project and some directions that can be used to reproduce the problem, and post the Feedback number here once you do. I'll check the status next time I do a sweep of forums posts where I've suggested bug reports and post any information about changes I am able to share to this thread. Bug Reporting: How and Why? has tips on creating your bug report.