## TL;DR
`withCredentials` resolves IDs against a specific store, domain, and scope; a typo, a folder-scoped credential, or a domain mismatch all produce "no credentials found". Open the credentials page, copy the exact ID, and confirm the pipeline can see that store. The binding then resolves.

## Error
```text
jenkins credentials binding: no credentials found with id
```

## Steps
1. Open the Jenkins credentials page for the relevant store (global, folder, or user) and find the credential. Expected: you see the exact ID string; copy it rather than retyping.
2. Check the domain: credentials under a non-global domain are only visible to matching URLs. Expected: the credential sits in a domain your pipeline can use, or you move it to the global domain.
3. Check the scope: folder-scoped credentials are invisible to pipelines outside the folder. Expected: the credential's scope covers the job, or you recreate it at global scope.
4. Fix the `withCredentials` block to use the exact ID from step 1, with the right binding type (string, username-password, file). Expected: the pipeline syntax matches the credential kind.
5. Re-run the pipeline. Expected: the binding resolves and the secret is available in the build environment.

## When to use
- `withCredentials` fails with "no credentials found with id"
- Pipelines moved between folders lose credential access
- New credentials that the pipeline cannot see

## When not to use
- The binding resolves but the value is wrong (update the credential)
- Agent-side file permission errors (different layer)

## Tool compatibility
- Jenkins credentials plugin, `withCredentials` pipeline step; global, folder, and user scopes

## Variant phrasings
### jenkins credentials id not found in pipeline
Copy the ID from the credentials UI; visually similar characters and trailing spaces cause most misses.

### folder credentials invisible to pipeline
Folder-scoped credentials only serve that folder's jobs; use global scope for shared pipelines.

## Why it happens
Jenkins credentials form a hierarchy of stores, domains, and scopes, and `withCredentials` searches only the stores visible to the current build. Anything outside that visibility (wrong folder, restricted domain, typo) is indistinguishable from "does not exist".

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_BLAUXLPFx-pbjKvg1bHdtg