Allow host execution without inheriting the parent process environment
Act version
v0.2.89 / master 4f411281417e88660bea1c1a1749aa71ae0bd60f
Feature description
Add an opt-in mode for host execution (-P <runner>=-self-hosted) that does not inherit the parent act process environment.
User story
When I deliberately run a job directly on the host, I want to choose which environment variables enter that job. This lets local workflow testing avoid implicitly exposing unrelated credentials, configuration, and session state from the shell that launched act.
Host execution currently merges every entry from os.Environ() into the job environment when the workflow has not already defined that key:
The current workaround is to launch act through an external environment-scrubbing wrapper. That wrapper must maintain a platform-specific allowlist for basics such as executable lookup and temporary directories, which is easy to get wrong and cannot express the intent as an act option.
Proposed behavior
Provide an opt-in flag such as --host-env=explicit or --no-host-env (exact naming is open to maintainers):
- Preserve today's inheritance behavior by default.
- In explicit mode, do not merge arbitrary variables from
os.Environ()into host-executed jobs. - Continue to provide the runner and GitHub context variables constructed by
act, plus the minimal host variables required foractto launch the selected shell reliably. - Continue to honor variables supplied explicitly through workflow/job/step
env,--env, and--env-file. - Scope the option to the host executor; container execution should not change.
For example, with a parent-only variable set:
ACT_PARENT_ONLY=sentinel act -P ubuntu-latest=-self-hosted --host-env=explicit
ACT_PARENT_ONLY should be absent inside the job. Passing --env ACT_PARENT_ONLY=sentinel should make it present.
Acceptance criteria
- A test proves that an arbitrary parent-process variable is absent in explicit host-environment mode.
- A test proves that the same variable is available when passed with
--env. - Required runner/context variables and shell execution still work on supported host platforms.
- Existing invocations retain their current behavior unless the new mode is selected.
This is an environment-selection control, not a sandbox: host jobs can still read host files or otherwise affect the machine according to the commands they execute.
Source: nektos/act