Skip to content

recent -X options do not auto-propagate to multiprocessing processes #146004

Description

@gpshead

Bug report

Bug description:

-X lazy_imports, -X thread_inherit_context, and -X context_aware_warnings are not inherited via subprocess._args_from_interpreter_flags() so multiprocessing spawned child processes do not inherit these -X settings unless the user happens to be using the dangerous non-default "fork" start method.

We should consider this for every -X option added. In general the answer should be "yes". There's a list in Lib/subprocess.py to update. (could we automate this by making the list an opt-out instead of a remember-when-adding-a-feature-to-opt-in list?)

Linked PRs

Activity

  1. added
    type-bugAn unexpected behavior, bug, or error
    3.15bugs and security fixes
    on Mar 15, 2026
  2. self-assigned this
    on Mar 16, 2026
  3. gpshead commented on Mar 16, 2026

    @gpshead
    MemberAuthor

    Potentially security relevant for -X disable-remote-debug. though i expect people who really want that off build a python without it or at least use the PYTHON_DISABLE_REMOTE_DEBUG= env var.

  4. added a commit that references this issue on Mar 16, 2026
  5. gpshead commented on Mar 16, 2026

    @gpshead
    MemberAuthor

    -X options that are not yet being propagated to multiprocessing spawned children that the PR would change:

    ``context_aware_warnings``,
    ``cpu_count``,
    ``disable-remote-debug``,
    ``int_max_str_digits``,
    ``lazy_imports``,
    ``no_debug_ranges``,
    ``pathconfig_warnings``,
    ``perf``,
    ``perf_jit``,
    ``presite``,
    ``pycache_prefix``,
    ``thread_inherit_context``,
    ``warn_default_encoding``.

    thoughts on if any of those should not auto-propagate to non-fork'ed children?

  6. gpshead commented on Mar 16, 2026

    @gpshead
    MemberAuthor

    And among those, which ones we should specifically backport propagation as a bugfix?

  7. added
    3.14bugs and security fixes
    3.13only security fixes
    on Mar 16, 2026
  8. vstinner commented on Mar 27, 2026

    @vstinner
    Member

    thoughts on if any of those should not auto-propagate to non-fork'ed children?

    IMO it's safe to propagate all of them to child processes.

    And among those, which ones we should specifically backport propagation as a bugfix?

    I'm fine with backporting your change which propagate the whole sys._xoptions directory.

  9. added a commit that references this issue on Mar 28, 2026
  10. added a commit that references this issue on Mar 28, 2026
  11. gpshead commented on Mar 28, 2026

    @gpshead
    MemberAuthor

    status: awaiting a manual backport to 3.13.

  12. added a commit that references this issue on Mar 28, 2026
  13. added a commit that references this issue on Mar 29, 2026
  14. added a commit that references this issue on Mar 29, 2026
  15. added a commit that references this issue on Mar 29, 2026
  16. added 2 commits that reference this issue on Apr 16, 2026
  17. added 2 commits that reference this issue on Apr 25, 2026
  18. added 2 commits that reference this issue on Aug 17, 2026
  19. added a commit that references this issue on Aug 17, 2026
  20. added a commit that references this issue on Aug 18, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Labels

3.13only security fixes3.14bugs and security fixes3.15bugs and security fixesstdlibStandard Library Python modules in the Lib/ directorytopic-multiprocessingtype-bugAn unexpected behavior, bug, or error

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions