Skip to content

[Modular] Provide option to disable custom code loading globally via env variable #12177

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 4 commits into
base: main
Choose a base branch
from

Conversation

DN6
Copy link
Collaborator

@DN6 DN6 commented Aug 18, 2025

What does this PR do?

Based on discussion here:
#12033

Add an option to globally disable any downloading of remote code via an env variable. This is a bit of a guard against wrapper code around diffusers that might automatically download remote code without the user knowing.

Note. It's not 100% foolproof since wrapper code could also override the env variable before doing any diffusers imports. I don't have a great solution for this at the moment. For now, I've added a warning for every time remote code is downloaded so that the user is at least alerted when this is happening.

cc: @JoeGaffney

Fixes # (issue)

Before submitting

Who can review?

Anyone in the community is free to review the PR once the tests have passed. Feel free to tag
members/contributors who may be interested in your PR.

@DN6 DN6 requested review from yiyixuxu and asomoza August 18, 2025 08:01
@HuggingFaceDocBuilderDev

The docs for this PR live here. All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update.

@JoeGaffney
Copy link

Hey @DN6,

Thanks for this looks like a solid mechanism.

You’re right that someone could technically do:

os.environ["DIFFUSERS_DISABLE_REMOTE_CODE"] = "0"
import diffusers

But in practice, this is mostly fine. The env var is read at import time, so once diffusers is imported, the value is cached and later changes won’t affect behavior.

Making it opt-in is probably a good call to avoid breaking existing workflows. In production or more secure environments, users can enable this to enforce stricter control over remote code execution.

Copy link
Collaborator

@yiyixuxu yiyixuxu left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

thanks1

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants