Summary
I'm experimenting with the CLI and the VS Code extension for internal tooling development, and came across Profile Session Settings.
When I authenticated a new sandbox refreshed from prod, and pulled ProfileSessionSettings I was expecting valid metadata but found some really strange behaviour. Not sure if CLI, Extension or MetadataAPI issue, but we'll see.
In this sandbox, I have 46 profiles. When using the "SALESFORCE ORG BROWSER", it shows 17 profile session settings. Out of this 17 profileSessionSetting files, we have 4 that seems like a duplicate of another profileSessionSetting, except, the number suffix is different and the profile reference in the file is <profile xsi:nil="true"/>.
This, in itself is rendering this an invalid metadata, as here: https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_profilesessionsetting.htm it says:
When comaring this to the "real" profileSessionSetting file for the given profile, we can also identify, that values, like sessionTimeout are inconsistent too:
Also, according to this article: https://help.salesforce.com/s/articleView?id=000381149&type=1 , the numeric suffix should be different each time the metadata is retrieved:
"The numeric suffix (e.g., 1520955179238) will be different each time you retrieve the setting — this is working as designed."
However, this is not the case, and it is not only not changing between retrieves, but is exactly the same between orgs, as we have this file tracked since 2022, and has not changed between retrieves and across orgs:
Steps To Reproduce:
- Authenticate to a prod org, with some custom profiles
- Open the Salesforce Org Browser in VSCode
- Open the ProfileSessionSettings and press "Refresh Type"
- Observe the Profile Session Settings
- Retrieve them
- Authenticate to a sandbox org, based on the prod org.
- Refresh the Profile Session Settings type
- Observe, that the file names did not change
- Retrieve all
- Observe, that all of the filenames are the same
- Observe, that some of the files are invalid
Actual result
Some profile session results are duplicated, but the duplicate is an invalid metadata.
Additional information
Not sure, just an idea, the extension might be retrieving profileSessionData for deleted profiles. Not entirely the fault of the CLI, as for some reason, Salesforce keeps them probably, and even replicates them across systems, not sure how to be honest if the metadata is invalid.
However, I think there should be some check or validation within the extension so invalid metadata is either not retrieved, or a warning is shown, as there are several instances acorss many metadata, that after retrieval, the very same metadata cannot be deployed, even if no modifications were performed.
Project Info:
Project Info
Generated: 2026-07-16T14:48:48.924Z
Metadata
sourceApiVersion: 67.0
packageDirectories: 1
namespace:
Types
| Type |
Components |
Files |
Size (KB) |
| AuthProvider |
12 |
12 |
7 |
| ConnectedApp |
6 |
6 |
13 |
| CorsWhitelistOrigin |
2 |
2 |
0 |
| CspTrustedSite |
29 |
29 |
21 |
| CustomMetadata |
1828 |
1828 |
2237 |
| CustomObject |
635 |
9623 |
9860 |
| EntitlementProcess |
4 |
4 |
15 |
| ExternalClientApplication |
1 |
1 |
0 |
| ExternalCredential |
3 |
3 |
4 |
| ExtlClntAppConfigurablePolicies |
1 |
1 |
0 |
| ExtlClntAppGlobalOauthSettings |
1 |
1 |
3 |
| ExtlClntAppOauthConfigurablePolicies |
1 |
1 |
1 |
| ExtlClntAppOauthSecuritySettings |
1 |
1 |
0 |
| ExtlClntAppOauthSettings |
1 |
1 |
0 |
| FieldRestrictionRule |
2 |
2 |
2 |
| Group |
408 |
408 |
76 |
| IframeWhiteListUrlSettings |
1 |
1 |
0 |
| InternalDataConnector |
2 |
2 |
1 |
| NamedCredential |
7 |
7 |
5 |
| PermissionSet |
105 |
105 |
2388 |
| PermissionSetGroup |
24 |
24 |
12 |
| ProfilePasswordPolicy |
18 |
18 |
12 |
| ProfileSessionSetting |
17 |
17 |
8 |
| RemoteSiteSetting |
20 |
20 |
6 |
| Role |
4134 |
4134 |
2027 |
| SharingRules |
294 |
294 |
67 |
| Territory2 |
126 |
126 |
68 |
| Territory2Model |
2 |
2 |
0 |
| Territory2Rule |
83 |
83 |
46 |
| Territory2Type |
6 |
6 |
1 |
Org
| Key |
Value |
| Org type |
sandbox |
| Source tracking |
false |
| SourceMember count |
N/A |
Settings
| Setting |
Value |
| salesforcedx-vscode-metadata.showSuccessNotification |
true |
| salesforcedx-vscode-metadata.sourceTracking.pollingIntervalSeconds |
0 |
| salesforcedx-vscode-core.push-or-deploy-on-save.enabled |
false |
| salesforcedx-vscode-core.push-or-deploy-on-save.ignoreConflictsOnPush |
false |
| salesforcedx-vscode-core.detectConflictsForDeployAndRetrieve |
false |
| salesforcedx-vscode-core.clearOutputTab |
false |
| salesforcedx-vscode-core.show-cli-success-msg |
true |
| salesforcedx-vscode-core.telemetry.enabled |
false |
| salesforcedx-vscode-core.enable-sobject-refresh-on-startup |
true |
| salesforcedx-vscode-core.telemetry-tag |
|
| salesforcedx-vscode-salesforcedx.enableLocalTraces |
false |
| salesforcedx-vscode-salesforcedx.enableConsoleTraces |
false |
| salesforcedx-vscode-salesforcedx.enableFileTraces |
false |
| salesforcedx-vscode-apex.java.home |
C:\Program Files\Java\jdk-25.0.2 |
Environment
| Key |
Value |
| Salesforce CLI |
@salesforce/cli/2.142.7 win32-x64 node-v24.14.1 |
| Java |
java 25.0.2 2026-01-20 LTS |
| Editor |
Visual Studio Code |
| VS Code |
1.128.0 |
| Node |
v24.17.0 |
| OS |
Windows_NT 10.0.26200 |
Extensions (Salesforce)
| Extension |
Version |
| salesforce.apex-language-server-extension |
0.8.0 |
| salesforce.salesforce-vscode-slds |
2.0.12 |
| salesforce.salesforcedx-metadata-visualizer-vscode |
1.1.0 |
| salesforce.salesforcedx-vscode |
67.5.0 |
| salesforce.salesforcedx-vscode-apex |
67.5.0 |
| salesforce.salesforcedx-vscode-apex-log |
67.5.0 |
| salesforce.salesforcedx-vscode-apex-replay-debugger |
67.5.0 |
| salesforce.salesforcedx-vscode-apex-testing |
67.5.0 |
| salesforce.salesforcedx-vscode-core |
67.5.0 |
| salesforce.salesforcedx-vscode-expanded |
67.5.0 |
| salesforce.salesforcedx-vscode-lightning |
67.5.0 |
| salesforce.salesforcedx-vscode-lwc |
67.5.0 |
| salesforce.salesforcedx-vscode-metadata |
67.5.0 |
| salesforce.salesforcedx-vscode-org |
67.5.0 |
| salesforce.salesforcedx-vscode-org-browser |
67.5.0 |
| salesforce.salesforcedx-vscode-services |
67.5.0 |
| salesforce.salesforcedx-vscode-soql |
67.5.0 |
| salesforce.salesforcedx-vscode-ui-preview |
1.3.0 |
| salesforce.salesforcedx-vscode-visualforce |
67.5.0 |
| salesforce.sfdx-code-analyzer-vscode |
1.20.0 |
Most recent version of the extensions where this was working:
No idea
Summary
I'm experimenting with the CLI and the VS Code extension for internal tooling development, and came across Profile Session Settings.
When I authenticated a new sandbox refreshed from prod, and pulled ProfileSessionSettings I was expecting valid metadata but found some really strange behaviour. Not sure if CLI, Extension or MetadataAPI issue, but we'll see.
In this sandbox, I have 46 profiles. When using the "SALESFORCE ORG BROWSER", it shows 17 profile session settings. Out of this 17 profileSessionSetting files, we have 4 that seems like a duplicate of another profileSessionSetting, except, the number suffix is different and the profile reference in the file is
<profile xsi:nil="true"/>.This, in itself is rendering this an invalid metadata, as here: https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_profilesessionsetting.htm it says:
When comaring this to the "real" profileSessionSetting file for the given profile, we can also identify, that values, like sessionTimeout are inconsistent too:
Also, according to this article: https://help.salesforce.com/s/articleView?id=000381149&type=1 , the numeric suffix should be different each time the metadata is retrieved:
"The numeric suffix (e.g., 1520955179238) will be different each time you retrieve the setting — this is working as designed."
However, this is not the case, and it is not only not changing between retrieves, but is exactly the same between orgs, as we have this file tracked since 2022, and has not changed between retrieves and across orgs:
Steps To Reproduce:
Actual result
Some profile session results are duplicated, but the duplicate is an invalid metadata.
Additional information
Not sure, just an idea, the extension might be retrieving profileSessionData for deleted profiles. Not entirely the fault of the CLI, as for some reason, Salesforce keeps them probably, and even replicates them across systems, not sure how to be honest if the metadata is invalid.
However, I think there should be some check or validation within the extension so invalid metadata is either not retrieved, or a warning is shown, as there are several instances acorss many metadata, that after retrieval, the very same metadata cannot be deployed, even if no modifications were performed.
Project Info:
Project Info
Generated: 2026-07-16T14:48:48.924Z
Metadata
sourceApiVersion: 67.0
packageDirectories: 1
namespace:
Types
Org
Settings
Environment
Extensions (Salesforce)
Most recent version of the extensions where this was working:
No idea