Setting trust_remote_code=True tells the Transformers library to download and run Python modeling code that lives in the model repository, not in the library itself. You are executing someone else's code on your machine. Use it only for repos you have reviewed, and pin a commit.
Why the flag exists
Transformers ships many standard architectures. A model with a new design may not be in the library yet, so its authors put the modeling code in the repo. The Transformers documentation calls these custom models: they use the library's configuration and modeling classes, but the modeling code is not from Transformers.
To load one, you pass the flag. The library does not run that code unless you ask.
What the documentation says to do
The docs tell you to take extra precaution when loading a custom model. They note that the Hub scans every repository for malware, and still say you should be careful to avoid inadvertently executing malicious code. They add that, as an extra layer of security, you can load a custom model from a specific revision so you do not pick up code that has changed.
from transformers import AutoModel
model = AutoModel.from_pretrained(
"org-name/custom-model",
trust_remote_code=True,
revision="<full commit hash>",
)
A review routine before you set the flag
- Open the repo files. Find the Python files referenced by the config. Read them.
- Look for side effects. Network calls, subprocess use, file writes outside the model folder, and environment variable reads are red flags in modeling code.
- Check who published it. Is it an organization you know, or a new account?
- Pin the commit. Use the full commit hash as the revision. A branch name can move.
- Re-review on update. A new hash means new code. Treat a bump like a dependency upgrade.
- Run it away from secrets. Load the first time on a machine or container without cloud credentials, tokens or SSH keys.
Where this goes wrong in practice
The common failure is copy and paste. A tutorial includes the flag, a notebook is saved with it, and a year later the same line is running in a scheduled job with production credentials in the environment.
A second failure is an unpinned revision. Without it, the repo owner, or anyone who takes over their account, can change the code you run on next start.
You can search for this in your own code quickly.
grep -rn "trust_remote_code" .
Every hit should have an owner, a reason and a pinned revision beside it.
Policy ideas that help
- Make trust_remote_code a reviewed exception, not a default.
- Keep an allow list of repos and commit hashes approved for use.
- Run model loading in jobs that do not hold production secrets.
Our overview of model hub supply chain risks covers how this fits with the rest of the exposure.
Where Safeguard fits
Safeguard can enforce policies and gates on pull requests, which is a natural place to catch a new use of this flag alongside dependency changes. It also provides SBOM and dependency scanning for the packages in the same project. A free scan is at gold.safeguard.sh/scan.
Quick check
Is the Hub malware scan enough to make remote code safe?
The Transformers docs say to remain careful even though the Hub scans repositories. A scan is a signal, not a review.
Do I need the flag for standard models?
No. It is for custom models whose modeling code is not part of the library.
Sources
Last reviewed: 19 October 2026.
