Unfortunately, one of the less-discussed aspects of these tools is that they do, indeed, come with risks related to execution of code and code-like things. There are two categories of code execution that can be involved in these coding agents: command line tools and your project code itself.
Xcode has a permission system that lets you govern when those command line tools get activated. We include by default a set of allowed tools that we believe should be relatively safe, but you can add or remove them freely. However, if you block every command line tool invocation, you will find that a lot of the power and delight of these agents is seriously reduced. The agents can revise code and test it, but their real power comes from the ability to string together layers of information in new and previously-unexpected-by-you ways, and a surprising amount of that comes in the form of activating command line tools to operate on cached information in the file system. To understand this experience better, I strongly recommend trying the tools out in a clean environment on a project you are building up from scratch, where you can feel comfortable trusting them to do creative-looking things. You may be surprised just how far this technology has come.
The other area, and this is a very important one to consider, is your project itself. A coding agent is designed to write code into your project, then do things like run unit tests to validate that the code it wrote is accurate. There's no getting around it: This is code execution, and you did not write that code. So you need to be prepared to trust the code that comes out of the coding agent and be OK with it being executed. That means trusting the input sources, and making sure that you don't over-entitle a process when you are using it with a coding agent. Xcode tries to help here, and won't let you launch a coding agent if you are running Xcode in a highly elevated state, but ultimately, some of these security decisions will have to be up to you and your comfort level.
