A step-by-step guide to installing and configuring Sourcegraph Cody in VS Code so it understands your Swift iOS codebase, while you keep building and running the app in Xcode.
By the end of this guide you will have Cody running in VS Code, signed in, and aware of your Swift project so it can answer questions and generate code with real context.
The goal is a two-window workflow: VS Code with Cody for AI assistance, and Xcode for building, running the simulator, signing, and shipping.
This setup does not replace Xcode. It adds an AI layer on top of the same Swift files your Xcode project already uses.
Allow roughly 15 to 20 minutes. You will need a Sourcegraph account with Cody access, since the standalone free tier was discontinued in 2025 and Cody is now primarily an Enterprise offering.
Install the latest stable VS Code for macOS if you do not already have it. Keep Xcode installed too, because you will still compile and run there.
Confirm you have Cody access. After Sourcegraph's 2025 plan changes, this generally means access through a Sourcegraph Enterprise instance or whatever current plan your organization holds.
Have your Swift project available locally as a folder. This can be an app project, a Swift package, or a workspace, as long as the source files live on disk where VS Code can open them.
Make sure you can sign in to Sourcegraph in a browser first. Verifying your login separately avoids confusion later when the extension asks you to authenticate.
Open VS Code and go to the Extensions view from the activity bar, or press the shortcut for extensions.
Search for 'Cody' by Sourcegraph. Confirm the publisher is Sourcegraph so you install the official extension rather than a lookalike.
Click Install. When it finishes, a Cody icon appears in the activity bar on the left side of the window.
Reload VS Code if prompted. A restart ensures the extension activates cleanly before you sign in.
Click the Cody icon to open its panel. You will see a prompt to sign in.
Choose the sign-in method that matches your account. For enterprise users this typically means connecting to your organization's Sourcegraph instance URL, then authenticating through the browser flow.
Complete authentication in the browser tab that opens, then return to VS Code. The panel should switch from a sign-in screen to the chat interface.
If sign-in fails, confirm you can log in to the same Sourcegraph URL in a normal browser tab. Most connection problems trace back to the wrong instance URL or an account without current Cody access.
Use File, Open Folder and select the root of your Swift project. Opening the true root, not a subfolder, gives Cody visibility into the whole codebase.
For a multi-module app, open the top-level directory that contains all modules so cross-file context works.
Let VS Code finish indexing the folder. You may see a language activity indicator while it scans files.
If VS Code suggests installing a Swift language extension, accepting it improves syntax highlighting and navigation. This is optional for Cody but pleasant for editing.
In the Cody chat panel, ask a question only answerable from your code, such as 'What does the main app entry point set up?' or 'Where is the networking client defined?'
A good answer that names your actual files and types confirms context is working. A vague, generic answer suggests Cody is not retrieving your files yet.
Make sure a relevant Swift file is open in the editor when you ask, since open files strongly inform context. You can also reference files or symbols explicitly in your prompt.
If answers stay generic, verify you opened the folder root and that your account's context features are enabled on your Sourcegraph instance.
Open a Swift file and start writing a function or a SwiftUI view. Cody should offer inline suggestions in grayed-out text; press Tab to accept or keep typing to ignore.
Next, select a block of Swift and use a Cody prompt or command, such as explaining the selection or generating documentation. This confirms the command surface works.
Try a small generation task, like 'add a computed property that formats this date for display,' then review the result. Always read what Cody produces before accepting it.
These two features, completions and prompts, are the core of daily use, so it is worth confirming both early.
Whenever you accept Cody-generated Swift, switch to Xcode and build. VS Code and Cody do not compile your app, so Xcode is your source of truth.
Run on the simulator or a device to confirm behavior, not just compilation. AI-generated code can compile yet behave incorrectly.
Run your unit tests after non-trivial changes. This catches regressions Cody cannot detect on its own.
Adopt a rhythm: reason and draft in VS Code with Cody, then build, run, and test in Xcode. That loop keeps you fast without trusting unverified output.
Add a project configuration or ignore rules so Cody does not pull in generated files, build artifacts, or vendored dependencies you do not want as context.
Keep only the files you are actively working on open in tabs, since open files heavily influence suggestions. A focused editor produces more focused answers.
Consider a consistent naming and structure convention in your Swift code. The clearer your codebase, the better Cody's context retrieval performs.
Finally, revisit Sourcegraph's documentation periodically. Features, model options, and settings evolve, and the official docs are the reliable source when your setup needs adjusting.
A common friction point is editing Swift in VS Code while Xcode holds the same files open. Both tools read from disk, so save in one before switching to the other to avoid working against a stale view.
When you accept a Cody suggestion, save the file, then let Xcode pick up the change on its next build. Xcode reloads externally edited files automatically in most cases.
If you use source control, commit in small steps as you go. That gives you a clean way to revert a Cody change that does not pan out once you actually build it.
Treat VS Code as the drafting surface and Xcode as the verification surface, and the two-window setup stays predictable rather than chaotic.
If the Cody panel never leaves the sign-in screen, the usual culprit is the wrong instance URL or an account without current access. Confirm both in a browser first.
If answers come back generic, you likely opened a subfolder instead of the project root, so Cody cannot see the whole codebase.
If inline completions never appear, check that autocomplete is enabled in settings and that no second AI extension is competing for the same suggestion slot.
Address these three early and the rest of your setup tends to fall into place without deeper debugging.
Yes. Cody in VS Code helps you read and write Swift, but you must build, run the simulator, sign, and submit the app in Xcode with an Apple Developer Program membership.
Usually because you opened a subfolder instead of the project root, or no relevant Swift file was open. Open the repository root, keep a related file open, and reference specific files in your prompt.
The standalone Cody Free and Pro plans were discontinued in 2025. Access now generally comes through a Sourcegraph plan such as Enterprise, so check the official pricing page for current options.
Yes. Open the top-level folder that contains all modules so Cody can retrieve context across the whole codebase rather than a single module.