Salesforce Services extension is unresponsive 66.5.4

[alan-morey]

Summary

My VS Code extenions updated to latest versions and now I cannot edit any Apex code in a realistic way, there is 8 seconds of delay for any keyboard input to be reflected in code editor. Looking at "Running Extensions" I see "Salesforce Services" 66.5.4 is marked as Unresponsive.

I found related issue #7160, I tried following suggestions there, uninstalled all Salesforce extensions, cleared out global extensions folder. Restarted VS Code, text editing of Apex works without issue now that there are no Salesforce Extensions.

Next, I install "Salesforce Extension Pack" v66.5.4 and restart VS code, now the Apex editor is unusable again and Salesforce Services 66.5.4 is marked as Unresponsive.

Workaround

Downgrade Salesforce Services extension to specific version v66.4.4, now Apex code editing is working for me without issue!

Salesforce Extension Version in VS Code: 66.5.4
Salesforce CLI Version: @salesforce/cli/2.130.9
OS and version: Ubuntu 22.04.5 LTS
VS Code version: 1.115.0
Most recent version of the extensions where this was working: 66.4.4 This is a guess, not sure which recent version of extension was actually installed but it was working correctly Friday April 10th and I'm only experiencing this issue since today, April 13th.

[svc-idee-bot]

Thank you for filing this issue. We appreciate your feedback and will review the issue as soon as possible. Remember, however, that GitHub isn't a mechanism for receiving support under any agreement or SLA. If you require immediate assistance, contact Salesforce Customer Support.

[svc-idee-bot]

Hello @alan-morey 👋 It looks like you didn't provide all the required basic info in your issue.

If you haven't already, please provide the following info:
Salesforce Extension Version in VS Code:
Salesforce CLI Version:
OS and version:
VS Code version:
Most recent version of the extensions where this was working:

Here's an example of a set of required info that will pass the validation:
Salesforce Extension Version in VS Code: 60.13.0
Salesforce CLI Version: @salesforce/cli/2.42.6 darwin-arm64 node-v18.18.2
OS and version: MacOS Sonoma 14.5
VS Code version: 1.89.1
Most recent version of the extensions where this was working: 60.11.0

A few more things to check:

• Make sure you've provided detailed steps to reproduce your issue, as well as all error messages that you see.
  • A repository that clearly demonstrates the bug is ideal.
  • Error messages can be found in the Problems Tab, Output Tab, and from running Developer: Toggle Developer Tools in the command palette.
• Make sure you've installed the latest version of the Salesforce Extension Pack for VSCode. (docs)
• Search GitHub for existing related issues.

Thank you!

[ksajdowski]

sf org disable tracking resolved it for me. Otherwise a process behind the extension host is constantly running at 100% of CPU making the whole IDE unresponsive and hard to work with simple commands like retrieve or deploy metadata.

[AndrewStopchenko-SO]

It’s important to outline the implications of disabling the source tracking.

The risky one is that the conflicts checking gets disabled for retrieve/deploy operations.
https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_dev_source_tracking.htm

If multiple developers are working in a shared org/sandbox, a developer with disabled source tracking can:

• overwrite org-only changes of other developer, if deploying those components to org, or
• lose local-only changes, if re-retrieved those components from org.

[ksajdowski]

In that case you can either:

• communicate to each other
• commit your work often to the repo
• set "salesforcedx-vscode-core.detectConflictsForDeployAndRetrieve": true in your IDE settings

[nwcm]

Yeah, this latest extension release has made our teams VS code unusable. We have a very large source > 10k components and basic vs code functions fail or take minutes. e.g. searching for a file

[mshanemc]

For the folks still experiencing this with 66.5.4 I need some help reproducing it. So far, I've testing with a 10k+ component project, and on an org with more than 80k SourceMembers.

From what I can tell, it seems that sf org disable tracking solves it, which means this is probably in sourceTracking, either the library itself or our usage of it from the extensions.

detective questions

1. with tracking still on, is sf project deploy|retrieve preview performant?

• 1a. is it only slow the first time you run it (querying and building the local tracking files) and better after that?
  2.if you open vscode and then wait a minute...does it "settle down" and start behaving or remain stuck (that is, it finishes all its tracking work and is then ok or it's never going to finish)?

3. how many sourceMembers are we talking about in the org. sf data query -t -q "select count() from SourceMember"
4. for the very large projects...what's the makeup of components?
5. if you were to set sourceTracking.pollingIntervalSeconds to 0 (no poll) does that solve it?
6. if you disable enable-sobject-refresh-on-startup does that help?
7. if you disable the agentforce vibes extension, does it help?

[nwcm]

env info

vs code

Version: 1.116.0 (user setup)
Commit: 560a9dba96f961efea7b1612916f89e5d5d4d679
Date: 2026-04-15T00:28:13Z
Electron: 39.8.7
ElectronBuildId: 13797146
Chromium: 142.0.7444.265
Node.js: 22.22.1
V8: 14.2.231.22-electron.0
OS: Windows_NT x64 10.0.26100

SF CLI

@salesforce/cli/2.130.9 win32-x64 node-v24.14.1

JDK

openjdk 21.0.10 2026-01-20 LTS
OpenJDK Runtime Environment Temurin-21.0.10+7 (build 21.0.10+7-LTS)
OpenJDK 64-Bit Server VM Temurin-21.0.10+7 (build 21.0.10+7-LTS, mixed mode, sharing)

enabled extensions

Only SF extensions enabled

All extension settings as default except for "salesforcedx-vscode-metadata.showSuccessNotification": true

ORG / metadata info

• sf data query -t -q "select count() from SourceMember" Total number of records retrieved: 13849.

Answers

1. with tracking still on, is sf project deploy|retrieve preview performant? No is it ~7x slower
   1a. is it only slow the first time you run it (querying and building the local tracking files) and better after that? Seems worse first time but still very slow after
2. if you open vscode and then wait a minute...does it "settle down" and start behaving or remain stuck (that is, it finishes all its tracking work and is then ok or it's never going to finish)? First time opening vs code can be unusable for 4-6 minutes. drop downs don't work, changing branch or searching files near impossible.
3. how many sourceMembers are we talking about in the org. sf data query -t -q "select count() from SourceMember" 13849
4. for the very large projects...what's the makeup of components?

Code Components

Type	Count
Apex Classes	1,940
Apex Triggers	59
LWC Components	608
Aura Components	195
Visualforce Pages	7

Declarative / Metadata

Type	Count
Custom Objects	402
Custom Fields	4,823
Record Types	401
Validation Rules	130
List Views	170
Layouts	334
FlexiPages	92
Quick Actions	72
Tabs	62
Flows	11
Path Assistants	8
Platform Events	5
Custom Applications	3

Security & Access

Type	Count
Permission Sets	48
Profiles	3
Named Credentials	1

Other Metadata

Type	Count
Static Resources	34
Custom Metadata Records	33
Custom Labels (files)	1

5. if you were to set sourceTracking.pollingIntervalSeconds to 0 (no poll) does that solve it? ``
6. if you disable enable-sobject-refresh-on-startup does that help? is it disabled, still occurs
7. if you disable the agentforce vibes extension, does it help? not installed, still occurs

details

deploy test 1, 1 apex class

• click deploy to org -> 58.60 seconds until anything occurred
• 37 seconds task bar "refreshing"
• 2 seconds for "successful deploy" message

deploy test 2, 1 apex class

• click deploy to org -> 28 seconds until anything occurred
• 8.26 until "successful deploy" message
• 41 seconds for refreshing to complete

deploy test 3, 1 apex class

• 22.29
• 7.19
• 42.28

all completed with same apex class
without source tracking takes around ~4 seconds to complete

larger deploy test

No source tracking

130 components - 41s
130 components - 23s
130 components - 21s

Source Tracking enabled

130 components - 1:55. 46 seconds no feedback -> 35 seconds "refreshing" -> 28 seconds "deploying" -> 3 seconds "success message"
130 components - 0:56. 21 seconds no feedback -> 30 deploying and refreshing -> 4 seconds until success
130 components - 1:34. 23 seconds no feedback -> 29 seconds deploying -> 4 seconds until success -> 37 seconds until refresh finished

It looks that the polling refresh may be "blocking"

Source Tracking enabled - Polling disabled

130 components - 1:30. 22 seconds no feedback -> 37 seconds refreshing -> 27 seconds deploying -> 4 seconds until success
130 components - 1:32. 24 seconds no feedback -> 2 seconds refreshing -> 26 seconds deploying -> 4 seconds until success -> 36 seconds until refresh completed
130 components - 2:29. 1:16 seconds no feedback -> 38 seconds refreshing -> 31 seconds deploying -> 4 seconds until success

Comments

I'm providing this data for your benefit. Our team uses individual scratch org per developer, so we really have no use case or benefit from source tracking as we have git. And actually, thought it had been disabled as we had configured "--no-track-source" in our scratch cli creation (which does not disable source tracking).

I may suggest features like this be opt-in over opt-out in future to allow a more predictable developer experience in the SFDX land. We have now disabled auto updated for Salesforce extensions and correctly applied sf org disable tracking to our orgs.

[RyanHipkiss]

I raised that original issue in v66.5.2, it seemed to be fixed as they mentioned, and now today it's stopped working again.

Is this being looked into?

[mshanemc]

And actually, thought it had been disabled as we had configured "--no-track-source" in our scratch cli creation (which does not disable source tracking)

that's really odd. If you look in the scratch org auth file, ex cat ~/.sfdx/test-1ti9inonzkwd@example.com.json
does it have a tracksSource property? if you create one with --no-track-source does it show up as false? (the sf org disable tracking is toggling that prop in the auth file, too).

---

some perspective: if you've got 2k remote change, 5k local and 5k of conflicts, are you really using tracking? everything (including CLI deploy/retrieve) would be faster with it turned off.

[mshanemc]

I raised that original issue in v66.5.2, it seemed to be fixed as they mentioned, and now today it's stopped working again

@RyanHipkiss yeah, I'm trying to find some way to reproduce it so I can see what the root cause is. Any idea what may have changed in the org/project between when it seemed better vs worse?