Build aborts at withCredentials when duplicate credential IDs span system and folder stores

Direct Answer

The deterministic resolution order for a Pipeline or freestyle run is: folder-scoped credentials (if the item lives in a folder that defines a credentials store) → system (global) credentials → user-scoped credentials. The first provider that returns a non-null Credentials instance for the requested ID wins. This order is identical for freestyle build wrappers and Pipeline withCredentials steps because both use the same CredentialsProvider.lookupCredentials() API when the run executes in the same item context.

Confirmed Behavior

• Folder-scoped credentials are only visible to items that are descendants of that folder. Moving or copying a job out of the folder removes access to those credentials, causing fallback to system or user stores — or failure if no other store contains the ID.
• Duplicate IDs across stores are not an error; the binding step completes with the first match. The value injected depends entirely on the run's item context and the provider ordering above.
• Resolution does not differ between freestyle and Pipeline for the same item context. It does differ between root-level items (no folder store in the chain) and folder-scoped items (folder store checked first).

Plugin Version Milestones

No later release has changed this order. If your controller pins Credentials plugin < 2.3.0, user-scoped credentials may not participate at all. Re-test after upgrading past these versions.

Caveats That Can Alter Precedence

• Custom CredentialsProvider implementations (HashiCorp Vault, CyberArk, proprietary plugins) can insert themselves at arbitrary priority via @Extension ordering, potentially changing the effective precedence.
• JCasC YAML order does not control runtime precedence — the provider ordering described above does.

Verification Steps for Your Controller

1. Open Manage Jenkins → Credentials → System (global) and any folder's Credentials page; note duplicate IDs.
2. Create a minimal Pipeline:

   withCredentials([string(credentialsId: 'DUP_ID', variable: 'SEC')]) {\n  echo \"bound: ${env.SEC}\"\n}

   Run it from the folder and from root; observe which value is injected.
3. Check installed plugin versions: Credentials, CloudBees Folders, and any third-party credential providers. Compare against the milestones above.
4. Enable FINE logging for com.cloudbees.plugins.credentials and com.cloudbees.hudson.plugins.folder during a run to see the exact provider lookup sequence.

One Diagnostic Detail Needed

Do you have any third-party credential provider plugins installed (Vault, CyberArk, AWS Secrets Manager, etc.)? If yes, their @Extension ordering can override the standard folder→system→user precedence, and the recommendation shifts to auditing those providers' priority.