“We are unable to process your request”

I opened one last week. Case-ID: 18860388 I don't think that’s a valid bug number. Details on the bug filing process are here, and the numbers are prefixed FB. Again, please upload the full spintrace to that bug and then post the bug number back here. It definitely revised (well, APFS), that's holding the lock. Sure, but the question is why, not who. Causes this kind of hang are the interactions between multiple locks and multiple processes. It's hard to pick up unless you're looking at the full log and know what you're looking for, but the basic form is that there are two locks: The outer lock, which the blocking thread (in this case, thread 0xc0616d) is inside and holding. The inner lock, which the blocking thread (thread 0xc0616d) is stuck waiting on. You can actually see this dynamic in the traces you sent. This lock is an APFS-owned lock: *940 apfs_vnop_getattr + 312 (apfs + 604336) [0xfffffe000beacff0] *940 IORWLockRead + 144 (kernel.release.t6000 + 496568) [0xfffffe00088e53b8] And, un

Hi, Thank you for the follow-up and for confirming the AASA multi-App ID support, that is a useful detail. Just to make sure we fully understand the recommendation: are you suggesting we add the testing platform's Team ID + Bundle ID to our AASA file so that their re-signed build is also a trusted app for our domain? If so, we want to understand the security implications of listing a third-party signing identity in our AASA file before going down that path. Regarding TestFlight, we are already using it for manual pre-release testing and it works well for that purpose. Our challenge is specifically with automated UI testing in a cloud device farm, where TestFlight distribution is not part of the workflow. We also wanted to ask about a hybrid distribution approach we are considering, and whether it is permitted under Apple's terms: Use the Apple Developer Enterprise Program to distribute the app internally to our cloud-based testing infrastructure, allowing their re-signing process to work under an Ent

@DTS Engineer the ticket was closed with Investigation Complete - Unable to Diagnose with Current Information., i submitted the stacktrace in the bug ticket, but i have no clue if i need to open another ticket for someone to check if now the information is enough or something like that, can you clarify?

Thanks for the detailed response! To answer your questions: OAuth - I don't see a pattern other than time. It seems to lose the OAuth token 2 or 3 times per day. It also doesn't seem to depend on idle time. I can be in the middle of working and it will lose the token. Yes, especially since thinking can go off the rails or go into a nearly-endless loop, this serves as a way to monitor and guide agent progress. I did file a feedback on all the issues, btw! (FB22310171 on the whole set of issues, and I also just filed FB22316631 per your request on this specific one.) Next time this occurs, I will attach it to the Feedback report. No, I have never downloaded or setup Codex. I especially want to highlight the additional bug I reported in my Feedback report but did not post here -- the agent will take action even if I specifically tell it to ask for approval before proceding. This is concerning because there is now some internal state where the agent believes it has gotten permission even though it hasn't

First, thank you for taking the time to post these. We really love hearing from our developers because this helps us make the tools better. Re: OAuth — hmm, OK we're investigating. Is there any pattern to this? Do you see this after a certain amount of time? Re: Thinking — interesting, this is good feedback about how you're using thinking as progress tracking. We know about the issue where you can't open the popover until the thinking is done. But, sounds like you really want a don't put thinking in a bubble entirely because that's part of your tracking of the agent progress. Makes sense. It'd be great if you could file a feedback request specifically for this. Re: Slowness to start — yeah, I agree that sounds weird. The only way we have to debug this at the moment is if you attach the contents of your conversation via the Bug button at the bottom of the transcript. Re: Codex & Claude showing — Have you downloaded both agents using the Intelligence settings even if you haven't logged in? We suppo

@frmoraess Thanks for doing that. Soon that bug will route to the correct team as I don't know why that is happening at all. I'm sure that team will let you know what is happening after they have the chance to take a look. You can see the status of your feedback in Feedback Assistant. There, you can track if the report is still being investigated, has a potential identifiable fix, or has been resolved in another way. The status appears beside the label Resolution. We're unable to share any updates on specific reports on the forums. For more details on when you'll see updates to your report, please see What to expect after submission. Albert Pascual
  Worldwide Developer Relations.

The error happens exactly when requesting to create a document. It looks like Claude is replying some document information to Xcode and Xcode cannot handle the information because it cannot be decoded as TextEditorCommand.

There are no guarantees that SLC events will arrive simultaneously for different apps. First of all, the SLC is a relative distance service. When the app started the request will matter. Then how quickly they have processed the previous event and returned would matter. The load of the app on the main thread (which is the thread these events are delivered by default) will effect how fast the events are delivered to the callback function. And last but not least, the delivery of events to an app is controlled by the system and it will decide when an app, which is already not running in the foreground (at least one of them will be in the background), will receive these events. If the apps are terminated (as opposed to just being suspended in the background), further throttles will apply. In summary, you cannot rely on two apps receiving the events at the same moment. If they do, you should consider those as happy coincidences, and not something to rely on in production.

@rlaurb Thanks for filling the bug. Looks like a known issue. You can see the status of your feedback in Feedback Assistant. There, you can track if the report is still being investigated, has a potential identifiable fix, or has been resolved in another way. The status appears beside the label Resolution. We're unable to share any updates on specific reports on the forums. For more details on when you'll see updates to your report, please see What to expect after submission. Albert Pascual
  Worldwide Developer Relations.