I wanted to see how I could integrate IBM Bob with Xcode, and I thought I’d share the setup with you all. My starting point was fairly simple: keep a project open in Xcode, have a conversation with Bob there, and ask Bob to build it through Xcode’s own tools.

I tried this with a small Swift package. By the end, Bob was answering in Xcode’s Coding Assistant and had successfully called its build tool. I also ran into a workspace path problem along the way.

The connection uses the Agent Client Protocol, or ACP. ACP lets an editor communicate with a coding agent. In this setup, Xcode starts a local bob acp process and provides the conversation interface. Bob Shell handles the agent session and model access. So you need Bob Shell installed, even though you’ll be talking to Bob inside Xcode.

I used Xcode 27.0 and Bob Shell 2.0.5. At the time of writing, IBM’s ACP documentation lists Zed, IntelliJ IDEA, and Neovim as supported editors. Xcode isn’t on that list. What I’m sharing here is the connection I tried with these versions, so check it with your own setup before depending on it for a project.

Getting Bob ready

I started with Bob Shell installed and Xcode through its initial setup. If you need Bob Shell, the installation instructions cover the available options. You’ll also need access to IBM Bob. I used an API key for this connection; an existing authenticated Bob Shell session is another option.

In Terminal, I checked the versions and found the executable paths:

xcodebuild -version
bob --version
bob acp --help
command -v bob
command -v node

On my Homebrew installation, those paths were /opt/homebrew/bin/bob and /opt/homebrew/bin/node. Keep your own results handy because you’ll enter them in Xcode shortly. My Bob executable is a JavaScript entry point, so Node.js needs to be available when Xcode starts it.

You don’t need to leave bob acp running in Terminal. Xcode starts it for you. Before opening the conversation in Xcode, I opened Bob against the project directory to set up workspace trust:

bob chat --workspace /path/to/your/project

Replace the path with your project’s directory, complete authentication if prompted, and review the trust prompt. I selected Trust folder for my small test project and then exited the session. Choose a project whose contents you’re allowed to send to Bob’s model service, since the agent can receive project context.

Keep the path exactly as Xcode sees it. I’ll come back to that, because I got caught by two different paths to the same folder.

Adding Bob to Xcode

In Xcode → Settings → Intelligence, I clicked Add an Agent…. That opens the Add an ACP Agent sheet, where I entered these values:

Use the absolute paths you found earlier, and add acp as its own argument row. Setting the interpreter explicitly gives Xcode the Node.js path it needs without relying on the environment from Terminal. 

For authentication, I added an environment variable named BOBSHELL_API_KEY and entered my Bob API key as its value. That’s the name documented on IBM’s ACP page. 

If you already use a stored Bob login, you can omit the API-key row. Without a key or stored token, Bob requires browser authentication. You may also encounter BOB_API_KEY in the general Shell documentation. Bob Shell 2.0.5 accepts that name too, but use only one.

There’s one detail to keep in mind here: Xcode saves the environment value in the agent’s local property list under ~/Library/Developer/Xcode/CodingAssistant/ACP/. That file contains your key if you enter one, so keep it out of shared diagnostics, along with screenshots of the real value. Exporting a key in Terminal doesn’t automatically make it available to Xcode when you launch the application from the Dock.

I kept the argument list at acp and clicked Add. Workspace trust was already set for the project, and I left tool approval enabled.

The first conversation, and the path that caught me

With the project open, I selected Coding Assistant in the top-left toolbar and chose New Conversation → Bob in the sidebar. For the first message, I kept the request small:

Reply with exactly BOB_XCODE_ACP_OK. Do not use tools.

My first attempt failed with The agent was unable to process the request. The problem was workspace trust. Xcode had opened /tmp/bob-xcode-validation, while Bob had recorded trust for /private/tmp/bob-xcode-validation.

On macOS, those paths can point to the same files. Bob treated them as separate workspace paths, so I opened another interactive session using the exact path Xcode was using:

bob chat --workspace /tmp/bob-xcode-validation

After selecting Trust folder for that path, I retried the conversation. Bob replied:

BOB_XCODE_ACP_OK

If you hit the same error, check the project path before changing authentication settings. The temporary path above belongs to my example; use your own project’s path. If the paths already match, check the conversation’s Diagnostics and Bob’s logs for another cause. I didn’t need to change credential-store preferences or manually create a credentials file on this Xcode build.

Asking Bob to build through Xcode

Now I could send a message and get a reply. Next, I wanted to try Xcode’s build tool. Xcode can expose development tools to the agent through the Model Context Protocol, or MCP. ACP carries the editor-agent conversation; MCP gives Bob access to tools such as BuildProject in this session.

On the first session, Xcode may ask you to allow mcp-use to access its tools. 

I sent this prompt in the same Bob conversation:

Use Xcode's build tool to build the current project. Do not edit files.
Report the tool you used and the build result. If the Xcode build tool is
unavailable, say so instead of using a shell command.

Xcode asked whether to allow Bob to run BuildProject (xcode-tools). I clicked Allow for that build. The tool call completed, and Xcode’s toolbar showed Build Succeeded. I could see both the completed call in the conversation and the build status in Xcode.

That’s how far I took this first try: a conversation with Bob inside Xcode and a successful build of a small Swift package through Xcode’s own tool. I haven’t tried a larger application or SwiftUI previews yet. The setup gives you a starting point for your own experiments.

I’d be interested to hear how this goes with your projects, especially which Xcode tools you try next.