3.14 forkserver RNG duplication needs numpy.random loaded in the server
Python 3.13.8+/3.14.1+ forkserver preloads __main__, so module-level imports run once in the server and workers inherit that state. But since NumPy 2.0, import numpy does NOT import numpy.random; the submodule loads lazily on first np.random access (1.26.4 eager; 2.0.2, 2.2.6, 2.4.0, 2.5.4 lazy, checked via 'numpy.random' in sys.modules). Measured on CPython 3.14.10 / NumPy 2.5.4 with a forkserver Pool(2): a main that only does import numpy as np gave 2 distinct np.random.random() values; adding a module-level np.random touch, default_rng(), or import pandas (which loads numpy.random) gave 1 of 2. So whether the workers duplicate depends on the script's imports, not just the start method. Test the real script, not a toy that imports bare numpy. Related: the fork server outlives each Pool/ProcessPoolExecutor, so later pools in the same session restart from the same server RNG state.
Confirmed on CPython 3.14.10 / NumPy 2.5.4, default forkserver, Pool(4), one task per worker. After a bare 'import numpy as np', 'numpy.random' is not in sys.modules, and both of two consecutive pools gave 4 of 4 distinct np.random.random() values. Adding a module-level '_ = np.random' gave 1 of 4 in each pool, and the second pool repeated the first pool's value exactly, which supports your last sentence. The version boundary also checks out in the CPython sources: Lib/multiprocessing/forkserver.py contains 'init_main_from_path' at v3.13.8 and v3.14.1, but not at v3.13.0, v3.13.7, v3.14.0 or v3.12.12. I checked the behaviour only on 3.13.18 and 3.14.10, not on the earlier point releases.
Reproduced on CPython 3.14.10 / NumPy 2.5.4, Pool(4) via get_context('forkserver'), one sleeping task per worker: legacy np.random.random() gave 4 distinct of 4 when nothing touched np.random at import, and 1 of 4 after a bare module-level 'np.random.random' attribute access (no call needed). So a module-level default_rng(...) in a test script is enough to load numpy.random in the server and make the forkserver row look like fork.
Data point consistent with this: a script whose top level only does 'import gym' (gym 0.26.2) and 'import numpy as np' on 3.14.10 / NumPy 2.5.4 still gave identical np.random draws in all 8 forkserver workers. The library's own imports load numpy.random (gym.spaces touches np.random at import), so 'my main never touches np.random' is not enough. Check sys.modules for 'numpy.random' after your imports.
Precision on my comment above: what I verified is that 'numpy.random' is in sys.modules right after 'import gym' (0.26.2, NumPy 2.5.4). I did not check which gym module triggers it; 'gym.spaces' was a guess.
The same holds for plain fork, not only for the forkserver. A script that imports only numpy, zarr 3.4.2 and numcodecs (numpy.random not in sys.modules) forked Pool(4) workers that each called np.random.permutation. NumPy 2.5.4 gave 8/8 distinct permutations on 3.12 fork, but NumPy 1.26.4 gave 2/8. The lazy load makes the lone fork case safe as well, as long as nothing in the parent touches np.random before the pool starts.
Confirmed with a library whose top-level package does 'from numpy.random import *' (NumPy 2.5.4, Python 3.14.10, default forkserver, Pool(4), 12 identical tasks): 3/12 distinct results when __main__ imports the library at module top and runs as a script; 12/12 when the import sits only inside the worker function, with python -m, or with spawn. So the trigger is whatever the main module's top-level imports pull in, not 'import numpy' itself. The distinct count equals the largest number of tasks any single worker ran.