[BUG] SourceKit shows false "Cannot find type in scope" diagnostics during live Edits on valid Swift code

Resolved 💬 4 comments Opened Apr 11, 2026 by Terryc21 Closed Apr 15, 2026

Preflight Checklist

  • [x] I have searched existing issues and this hasn't been reported yet
  • [x] This is a single bug report (please file separate reports for different bugs)
  • [x] I am using the latest version of Claude Code

What's Wrong?

When editing Swift files on an existing Xcode project, the <new-diagnostics> block returned after each Edit tool call reports Cannot find type 'X' in scope errors for types that are defined elsewhere in the same module and build fine. The diagnostics are stale-index false positives — xcodebuild resolves the types correctly and produces BUILD SUCCEEDED.

Every Swift file edit in an 8-hour session today produced this noise. The types flagged as "not in scope" included a SwiftData @Model class, a public enum, a manager class, and a SwiftUI component — all defined in sibling files within the same module, all resolved cleanly by the compiler, none of them actually missing.

Example diagnostics from a single Edit:

✘ [Line 21:15] Cannot find type 'Beneficiary' in scope (SourceKit)
✘ [Line 61:38] Cannot find type 'BeneficiaryRelationship' in scope (SourceKit)
✘ [Line 85:26] Cannot find type 'LegacyWishesManager' in scope (SourceKit)
✘ [Line 94:17] Cannot find 'SheetHeader' in scope (SourceKit)

All four types exist in the same module and the build passes. The Edit did not modify imports or @available annotations — the flagged lines were pre-existing, unchanged code.

The impact is that a model (or user) following diagnostics literally could revert correct edits, escalate unnecessarily, or waste turns investigating nonexistent errors. In this session the model correctly ignored the false positives after the first couple of edits and proceeded to ship 3 clean fixes, but only because it had enough Swift experience to recognize stale-index noise. A less experienced user would not know to ignore them.

What Should Happen?

Diagnostic feedback should either reflect compiler reality or be suppressed when the index is known stale. Three possible directions:

  1. Refresh the SourceKit index between Edit and diagnostic emission, so diagnostics match what the compiler would actually report
  2. Suppress Swift "Cannot find type in scope" diagnostics when the Edit did not touch imports, @available annotations, or module declarations — these are the only changes that can legitimately cause a type to become unresolvable
  3. Label stale diagnostics explicitly ("index may be out of date, run build to verify") so users and models weight them lower than actual build output. At minimum, document the behavior in the Claude Code Swift guide so users know live diagnostics are unreliable during edit cycles and to trust xcodebuild as the source of truth.

Error Messages/Logs

Steps to Reproduce

  1. Open Claude Code in an existing iOS/macOS Xcode project (Swift 6.2, Xcode 26.x, single source root under Sources/)
  2. Use the Edit tool to modify a SwiftUI View file that references types defined in sibling files within the same module (e.g., a view in Sources/Features/ that uses a @Model class from Sources/Models/)
  3. After the Edit lands, observe the <new-diagnostics> system reminder block
  4. Run xcodebuild -scheme YourScheme -destination 'generic/platform=iOS Simulator' build in the same session
  5. Compare: diagnostics will report types as "not in scope" while the build reports BUILD SUCCEEDED

Reproduced across three separate Swift files in today's session (BeneficiaryFormView.swift, SharedLegacyView.swift, NotificationSettingsView.swift).

Consistent pattern: Edit → false diagnostic → build passes cleanly.

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.98 (Claude Code)

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

Environment (will be in a field below the fold)

  • Claude Code version: [RUN claude --version AND PASTE HERE]
  • OS: macOS (Darwin 25.3.0)
  • Xcode: 26.3
  • Swift: 6.2
  • Project: Existing iOS/macOS Xcode project (~588 Swift files, ~205K LOC)
  • Source root: single, Sources/
  • Package dependencies: xctest-dynamic-overlay, swift-custom-dump, swift-snapshot-testing, sentry-cocoa, swift-syntax (all resolved)
  • Date observed: 2026-04-10 session

View original on GitHub ↗

This issue has 4 comments on GitHub. Read the full discussion on GitHub ↗