INVALID_SESSION_ID with External Client App in SOME orgs

[FeldhackerChrisPFG]

Describe the bug
We've been using the External Client App solution with OAuth for several weeks in orgs with API Access Control enabled. Worked great, no problems.
Recently, Data Loader started failing to connect to some orgs, with the logs showing:

INFO [Thread-1] com.salesforce.dataloader.client.LoginClient dologin (LoginClient.java:176) - Beginning Partner Salesforce login ....
INFO [Thread-1] com.salesforce.dataloader.client.LoginClient setConfiguredSessionId (LoginClient.java:232) - Using session id from OAuth PKCE Flow to establish Salesforce session
ERROR [Thread-1] com.salesforce.dataloader.client.LoginClient login (LoginClient.java:146) - Failed to get user info using manually configured session id
com.sforce.soap.partner.fault.UnexpectedErrorFault

Capturing the SOAP response shows the server is returning a "HTTP/1.1 500 Internal Server Error" response, with the message:
INVALID_SESSION_ID: This session is not valid for use with the API

To Reproduce
Steps to reproduce the behavior:

1. Setup an External Client App for Data Loader within the org with API Access Control enabled.
2. Configure Data Loader client with ECA settings.
3. Click "Export", choose "OAuth", then login to org via web browser
4. Web browser reports success, but Data Loader dialog stays open and console reports an exception.

If the ECA works in this org, keep trying other orgs until a problematic org is found.
Once a problematic org is found, assign the user the "Use Any API Client" system permission and re-test, and Data Loader will operate without issue.

Expected behavior
Data Loader should function properly against all orgs without requiring the "Use Any API Client" permission.

Desktop (please complete the following information):

• OS: Windows 11 Enterprise 23H2
• Version 64.1.0

Additional context
The problem does not appear to be Winter 26 related as both Summer 25 and Winter 26 preview orgs have exhibited the problem.
We suspect the issue could be related to the Connected App changes Salesforce pushed this month.
We have a case open with Salesforce corporate but wanted to report the issue here as well.
Perhaps there is something that could be improved on the Data Loader side to ensure the configured ECA/Connected App client id is consistently used?

One interesting observation is that if you also log the http headers during this request they appear as follows:
(Wire.java:73) - http-outgoing-1 >> "POST /services/Soap/u/64.0/ HTTP/1.1[\r][\n]"
(Wire.java:73) - http-outgoing-1 >> "SOAPAction: ""[\r][\n]"
(Wire.java:73) - http-outgoing-1 >> "Accept: text/xml[\r][\n]"
(Wire.java:73) - http-outgoing-1 >> "Content-Type: text/xml; charset=UTF-8[\r][\n]"
(Wire.java:73) - http-outgoing-1 >> "Sforce-Call-Options: client=DataLoaderPartnerUI/64.1.0[\r][\n]"
(Wire.java:73) - http-outgoing-1 >> "User-Agent: Salesforce Web Service Connector For Java/1.0[\r][\n]"
(Wire.java:73) - http-outgoing-1 >> "client_id: DataLoaderPartnerUI/[\r][\n]"

Seeing the "client_id" set to the default value rather than the custom value configured by the user seems strange. However, the same default client_id value is used with the request to the /token endpoint and it doesn't seem to have a problem, so perhaps this is unrelated.

[FeldhackerChrisPFG]

This appears to be related to a Known Issue that has been published:
https://help.salesforce.com/s/issue?id=a02Ka00000jg4dcIAA

But seems like the actual fix needs to happen on the Data Loader side.

[ashitsalesforce]

Thanks @FeldhackerChrisPFG . Does the workaround in the KI address your issue?

[ashitsalesforce]

Hi @Arpit-Barjati , thanks for confirming that the workaround works.

[FeldhackerChrisPFG]

Yes, I can confirm the workaround works, and the Known Issue does seem to match this problem. We had issues in "some"/most orgs due to user access being removed from the legacy Connected Apps, but other orgs still had access in place.

To summarize the bug: For orgs that choose to implement the External Client App approach with Data Loader, granting users access to the ECA alone is insufficient for Data Loader to function. Users must still be granted access to the "Dataloader Bulk" and "Dataloader Partner" Connected Apps as well.

[ashitsalesforce]

Thanks @FeldhackerChrisPFG for a crisp summary of the bug.