Swift completion dead in Trae? Here's a systematic fix — from verifying the toolchain to generating a compile database — so SourceKit-LSP lights up your code again.
When Swift completion fails in a VS Code-style editor like Trae, the problem is almost always the language server, SourceKit-LSP, not the editor itself.
SourceKit-LSP needs three things to work: a valid Swift toolchain, the ability to launch the server binary, and knowledge of how your files are compiled.
If any of those is missing, you get symptoms like no autocomplete, no hover documentation, no go-to-definition, or errors everywhere on code that actually compiles.
The good news is that the failure modes are finite and diagnosable. This guide walks them in order of likelihood.
Work through the steps sequentially rather than jumping around. Most cases resolve at the toolchain or compile-database step.
Open Trae's integrated terminal and run `swift --version`. If this fails, the editor cannot find Swift, and nothing else will work.
Run `xcode-select -p`. It should print a path inside your Xcode. If it points somewhere stale or at the bare Command Line Tools, that is your culprit.
Fix it with `sudo xcode-select -s /Applications/Xcode.app/Contents/Developer`, then restart Trae so it inherits the corrected environment.
Confirm the server binary exists with `xcrun --find sourcekit-lsp`. This should print a path; if it errors, your Xcode installation is incomplete.
A large share of 'completion is broken' reports end here. An editor launched before Xcode was configured simply never saw the toolchain.
Completion in Trae is driven by a Swift extension that starts SourceKit-LSP. Open the extensions panel and confirm the Swift extension is installed and enabled.
If it is installed but seems inactive, disable and re-enable it, or reload the editor window. Language servers sometimes fail to start on the first launch after install.
Check the extension's output or logs panel. Trae, like VS Code, surfaces a language-server log where startup errors appear in plain text.
A common message is that the server could not be found or failed to launch. That points you back to the toolchain step, so re-verify `xcrun --find sourcekit-lsp`.
Once the extension reports the server as running, half the battle is over. The remaining issues are about project context.
On a large project, SourceKit-LSP needs to index before completion is fully reliable. Immediately after opening a project, results can be sparse.
Watch for indexing activity in the status area. Give it a few minutes on a big codebase, especially the first time you open it.
Do not judge the setup as broken during the initial index. Test completion again once activity settles.
If you have many files open, close the ones you are not using. A leaner working set helps the server prioritize the code you care about.
If completion works after waiting but is slow every session, the project may simply be large, and a compile database plus fewer open editors will help the most.
This is the fix for the most stubborn cases. Swift Packages usually work without extra help, but app targets need a `compile_commands.json` compile database.
Without it, SourceKit-LSP does not know the build flags, module search paths, or which SDK each file uses, so completion for your own types and dependencies fails.
Generate `compile_commands.json` using an `xcodebuild`-based approach or a dedicated generator, and place the file at your workspace root.
Reload Trae so the server reads it. Completion for imported modules, framework symbols, and your app's own types should now resolve.
Regenerate this file whenever your build configuration changes significantly, because a stale compile database causes intelligence to lag behind reality.
If `swift build` works in Trae's terminal but completion still misbehaves, you may have multiple toolchains fighting each other.
Check whether you have standalone Swift toolchains installed alongside Xcode. Mismatched versions can cause the server to load the wrong SDK.
Align everything to your Xcode toolchain with `xcode-select`, and if the Swift extension has a toolchain-path setting, leave it on the default or point it explicitly at Xcode.
Restart Trae fully after any toolchain change. Language servers cache their environment at launch, so a reload is not always enough.
Once all paths point at one consistent toolchain, the intermittent, hard-to-explain completion failures typically disappear.
If completion is still broken, do a clean reset. Close Trae, and if the Swift extension keeps a language-server cache or index store, clear it.
Reopen the project root — not a subfolder — so the server can see `Package.swift` or your project file at the top level. Opening a nested folder is a surprisingly common mistake.
Regenerate the compile database, restart Trae, and give the indexer time before testing again.
If a specific file misbehaves while others work, check for syntax errors earlier in the file. A single unparseable region can suppress completion below it.
When all else fails, confirm the same project opens with working Swift intelligence in a known-good setup, which tells you whether the issue is the project or the editor configuration.
When the quick fixes do not land, the fastest path forward is to stop guessing and read what the language server is actually reporting.
Open the language-server output panel in Trae, the same way you would in VS Code, and watch it as you reopen a Swift file. Startup errors, missing-binary messages, and index failures usually appear there in plain text.
Separate the two layers deliberately. First prove the toolchain works on its own by running `swift build` or `swift --version` in the terminal. If the command line is healthy but completion is not, the problem is in the extension or its configuration, not the toolchain.
Then prove the project is understandable. Open a tiny throwaway Swift Package and confirm completion works there. If it does, your toolchain and extension are fine, and the issue is specific to your real project — most often a missing compile database on an app target.
This divide-and-conquer approach turns a vague 'completion is broken' into a specific, fixable statement about which layer failed. Almost every stubborn case collapses to either a toolchain path, a compile database, or opening the wrong folder as the project root.
Keep a note of what fixed it last time, because the same handful of causes tend to recur on new machines and new projects. A short personal checklist — verify the toolchain, confirm the extension, regenerate the compile database, reopen the root — will resolve the overwhelming majority of future failures in a couple of minutes.
Swift Packages are understood natively by SourceKit-LSP, while app targets need a compile_commands.json compile database describing each file's build flags. Generate one, place it at the project root, and reload Trae.
Verify the toolchain: run xcrun --find sourcekit-lsp and swift --version in Trae's terminal. If those fail, fix xcode-select to point at your Xcode, then restart Trae.
No. SourceKit-LSP runs locally. Only Trae's AI features need connectivity. If completion is broken, it is a local toolchain or configuration issue, not a network one.
Let the initial index finish, close unused files, and provide a compile database so the server does not have to infer build settings. Very large projects are inherently heavier to index.