Process.spawn environment inheritance behavior unspecified in Crystal

Environment variable propagation gap

Crystal's Process.spawn API accepts an optional env hash to define the child process environment, yet the documentation does not state whether the parent's environment is inherited when env is omitted. Empirical testing shows that variables set in the parent are absent in the spawned process unless explicitly forwarded.

Impact on reproducible execution

Scripts that depend on configuration supplied through environment variables—such as database URLs, API keys, or feature flags—fail silently when the child process starts with an empty or minimal environment. This behavior diverges from typical Unix fork/exec semantics where the environment is inherited by default, creating portability surprises for developers moving from other languages.

Security and validation concerns

Explicitly passing an env hash avoids the inheritance ambiguity but shifts the burden to the caller to validate and sanitize every variable. Accidentally forwarding secrets or omitting required variables can both lead to runtime failures or credential leakage.

• What is the exact default environment presented to a child process when env is not supplied to Process.spawn?
• Does the standard library provide a helper to merge the parent's environment with a custom hash, or must callers manually reconstruct ENV.to_h each time?
• Is there a version or platform where inheritance behavior differs from the observed empty-environment default?