Maybe I'm not understanding your request: is what you are asking for any different from Giving external agents access to Xcode? Afaict, you can't control Instruments via Xcode MCP, but you can easily find third-party MCP servers for that (I haven't tried any of them, so I have no idea how well they work).

Thanks @mattgallagher for pointing out that the “CLI should hold onto a single connection for the entire session”. In fact, I've found that it's the agent's responsibility, and not Xcode's, to keep the connection alive. After updating my agent's configuration, the issue is gone.

It's not specific to Codex. I'm having the same issue in Xcode 26.6 using an external CLI agent (Pi Coding Agent). It's as if Xcode grants permission to the client for a limited amount of time (or interactions), then it presents the confirmation dialog again. I'd be curious to know whether Xcode 27 (beta) still does the same.

what features am I missing out on by using a local model instead of a larger, cloud-based model? In terms of what Xcode exposes, I think that there is feature parity. As long as your LLM can communicate via the supported API (for chat mode), or the agent harness speaks ACP (for agentic mode), Xcode doesn't care where the model is running and, afaik, it doesn't enable any extra controls if you're using a cloud model compared to what is available when you use a local model. Big caveat, though: Xcode uses prompts that have likely been tested mostly with Claude and GPT (and now Gemini), and may not work well at all with your local model. There is no way currently to replace them (Apple engineers please correct me if I'm wrong). I wish there was a possibility for “advanced” users to tweak that. Is Xcode's ability to run tests, build the project, etc. limited by the use of a local model? Does it limit the ability to do more complex agentic workflows? If so, how? In Xcode, if you enable Settings > Intelligence > Allow external agents to use Xcode tools, an agent supporting MCP can control Xcode directly, and in my experiments a good local model will build and test Xcode projects just fine (and iterate in case of errors). Even if you don't enable MCP, the agent will probably try to use xcodebuild, xcrun, etc anyway, although the user experience is not as good because Xcode won't display the changes as it would otherwise do. Regarding the quality and complexity of agentic workflows, the key point is not Xcode, but the combination harness+model (+hardware, but that's not something one can usually change as often). Imo you should first get that working well outside of Xcode and then integrate it in Xcode, which may require additional tuning (and ACP compatibility—most ACP-enabled harnesses I've tried currently do not work with Xcode for some reason). what cloud-based models can offer that I don't already have. More computational power, hence more “intelligence” (scope, quality, performance). Whether that's necessary to you depends only on your needs. They may be also easier to set up in Xcode. Running a local model might also be less cost-effective at the moment, but I'm not sure. I'd rather spend a few more $$$ of electricity in any case to be in control. Nothing else. Environmentally, the best option is probably to avoid using anything. Ethically, many lines have been crossed already, but I believe that “open” models are the lesser evil going forward.

I did another test on two different machines seemingly configured in the same way (macOS 26.4.1, Xcode 26.5), and got divergent results. These are the steps I've taken in each case: In System Preferences > Privacy & Security, remove Xcode from Full Disk Access and Files & Folders. Reboot. Open a project under the Documents folder. The user is prompted to grant Xcode access to the Documents folder. If access is denied, Xcode correctly reports that it doesn't have permissions to open the project (Xcode can still create new projects inside Documents, but I assume that this is expected behavior). In System Preferences > Privacy & Security > Files & Folder, grant Xcode access to the Documents folder. Restart Xcode and reopen the same project. The project can now be opened. At this point, in one machine the preview shows up correctly, but in the other machine I get the “Failed to launch” error I've originally posted, and I need to apply one of the workarounds I've originally mentioned (move the project folder or toggle automatic refresh) to be able to see the previews. So, I cannot reproduce the issue consistently: there is something else going on in one of my machines, but I don't know how to debug it further. PS: Glad to know that the interaction is with humans making genuine mistakes! If you ever implement bots in this forum, I hope that they will clearly marked as such. My apologies to the engineers if my reply sounded harsh.

Is that an AI-generated answer? I have already mentioned that putting the project in a directory different from a “special” directory such as Documents works. I've posted my message to help people who may encounter the same issue, as it took me some time to figure it out. What is confusing here is that Xcode has full disk access, yet a project in Documents raises a permission error. Maybe there is some other process that is invoked by preview and needs to be granted access to the Documents folder (or any other “special” folder where the project is located)?