Stack and context environment variables missing from policy input: how to access them in plan and notification policies
Last updated: October 29, 2026
Overview
When you inspect input.spacelift.run.runtime_config.environment in the policy simulation panel, you may see only some of your environment variables. Variables set directly on the stack or attached through contexts are missing. This is expected: runtime_config.environment only includes variables defined in .spacelift/config.yml. Stack and context variables are not passed into policy input.
Option 1: Define variables in .spacelift/config.yml
The simplest approach for non-sensitive values is to add the variable directly to your .spacelift/config.yml file:
version: "1"
stack_defaults:
environment:
MY_VARIABLE: "<value>"Once added, the variable will appear in the policy input. Note that values defined here are visible in plain text in the repository and in the policy simulation panel, so this approach is only suitable for non-sensitive values.
For plan policies, the variable will be accessible at
input.spacelift.run.runtime_config.environment.For notification policies, the variable will be accessible at
input.run_updated.run.runtime_config.environment.
Option 2: Pass stack variables via a before_init hook (plan policies)
If you prefer to keep the variable defined on the stack rather than in the config file, you can pass it into your plan policy using a before_init hook and custom inputs.
Write the value to a custom JSON file at the root of your project in your before_init hook. For example:
echo "{\"my_variable\": \"$MY_VARIABLE\"}" > env.custom.spacelift.jsonYou can then read it in your plan policy from input.third_party_metadata.custom.env.my_variable. See the custom inputs documentation for more details.
Note: The value will be visible in plain text in the policy input and policy samples. Don’t use this approach for secret variables.
Option 3: Pass stack variables via policy flags (notification policies)
Custom inputs are not available in notification policies. Instead, you can pass a stack variable through a plan policy flag and then read it in your notification policy.
Write the variable to a custom JSON file using a
before_inithook, as described in Option 2.In your plan policy, set a flag containing the value:
flag contains sprintf("my_variable:%s", [input.third_party_metadata.custom.env.my_variable])In your notification policy, read the flag from
input.run_updated.run.flags.
Note: Policy flags are set when the plan policy is evaluated, after planning. Notifications for earlier run states won’t include the flag. The value will also be visible in plain text as a flag on the run, so don’t use this approach for secret variables.