The from-history flag exports only the packages you explicitly asked conda to install, not their dependencies. That makes the file small and portable across platforms. It also means the file is not a record of what is actually installed, so it is the wrong input for a vulnerability review.
What the docs say
The conda documentation recommends the from-history flag for maximum cross platform compatibility. It exports only explicitly installed packages and excludes platform specific dependencies. The documentation also notes that the flag works with structured formats such as environment-yaml, and not with plain text formats.
Two commands do the same job, the newer conda export and the older conda env export, each with the flag.
conda export --from-history --format environment-yaml
conda env export --from-history
What you gain
- A short file that a teammate on another operating system can use.
- A clear statement of intent, such as python and pandas, without hundreds of transitive lines.
- Fewer noisy diffs in version control.
What you lose
The solver chooses dependency versions at install time. Run the same short file next month and you may get different transitive packages. For a data science team that sounds like a reproducibility problem, and it is also a security problem, because a transitive library can carry an advisory you never chose.
| Need | Use |
|---|---|
| Share intent with a colleague on another OS | From-history export |
| Rebuild the same environment tomorrow | Explicit spec or a lock file |
| Know what is installed for a vulnerability scan | Full list of the live environment |
| Hand an auditor a record | Full list with versions and hashes |
A two file habit
Keep both files, because they answer different questions.
- Commit the from-history file as the readable source.
- Commit a full export or explicit spec produced from the same environment as the record.
- Regenerate both when you add or remove a package, and diff them in the same pull request.
- Scan the full one, not the short one.
If you scan only the from-history file, you test the packages you remember choosing and miss everything they pulled in.
A caution about pip lines
Packages installed with pip inside the environment are tracked differently, as covered in the conda pip guidance. Check that your exported file actually lists them, and test by rebuilding in a scratch environment.
Safeguard's SBOM and dependency scanning works from a full dependency list, which is the kind of record the second file gives you. The free scan at gold.safeguard.sh/scan is a quick way to see the difference.
Try it yourself
Click through it at your own pace, or open it full screen. Compare the short list of direct packages with the longer inventory behind it.
Quick check
Is a from-history file a good input for a vulnerability scan?
Not on its own. It lists only what you asked for. Scan the full installed list or an explicit spec.
Why is it still useful?
It is portable and readable, so it documents intent and keeps diffs small.
Sources
- Managing environments, conda documentation, fetched 19 October 2026.
Last reviewed: 19 October 2026.
