[GH-ISSUE #2209] [BUG] Env vars are not refreshed between scripts environements #3315

New issue

Open

opened 2026-03-14 07:06:50 +03:00 by kerem · 3 comments

kerem commented

2026-03-14 07:06:50 +03:00

Owner

Originally created by @P6g9YHK6 on GitHub (Apr 15, 2025).
Original GitHub issue: https://github.com/amidaware/tacticalrmm/issues/2209

Describe the bug
ENV is not refreshed between scripts environments for exemple when working between python and powershell require a restart of the agent.

To Reproduce
Steps to reproduce the behavior:

Run this:

$env:MY_VAR = "HelloFromPowerShell"
[System.Environment]::SetEnvironmentVariable("MY_VAR", "HelloFromPowerShell", "User")
Write-Host "Environment variable MY_VAR set to: $env:MY_VAR"

run this:

#!/usr/bin/python3
import os

value = os.environ.get("MY_VAR")
print(f"MY_VAR: {value}")

See that the var is empty
restart the agent
see that the var is not empty anymore

Expected behavior
env should be refreshed on each script run to avoid missing var set by another script.

Originally created by @P6g9YHK6 on GitHub (Apr 15, 2025). Original GitHub issue: https://github.com/amidaware/tacticalrmm/issues/2209 **Describe the bug** ENV is not refreshed between scripts environments for exemple when working between python and powershell require a restart of the agent. **To Reproduce** Steps to reproduce the behavior: 1. Run this: ``` $env:MY_VAR = "HelloFromPowerShell" [System.Environment]::SetEnvironmentVariable("MY_VAR", "HelloFromPowerShell", "User") Write-Host "Environment variable MY_VAR set to: $env:MY_VAR" ``` 2. run this: ``` #!/usr/bin/python3 import os value = os.environ.get("MY_VAR") print(f"MY_VAR: {value}") ``` 3. See that the var is empty 4. restart the agent 5. see that the var is not empty anymore **Expected behavior** env should be refreshed on each script run to avoid missing var set by another script.

kerem commented

2026-03-14 07:06:56 +03:00

Author

Owner

@silversword411 commented on GitHub (Apr 18, 2025):

This is expected behavior due to how environment variables are handled at the process level. When you set an environment variable in PowerShell (or any process), it only affects:

The current PowerShell process ($env:MY_VAR)

Optionally, the User or Machine registry (via SetEnvironmentVariable) — but changes there only apply to new processes started after the change.

Python (or any other script runner) will not see the updated variable unless it's started after the environment is refreshed, which typically means restarting the agent or the host process managing these scripts.

Why this happens: Each script runs in its own process context, and environment variables are inherited at process launch — they are not live-synced between processes.

Workaround: If you need to pass values between scripts, consider:

Using files or a shared temp location

Using custom fields (if Tactical RMM)

Restarting the agent or script host after setting persistent env vars

@silversword411 commented on GitHub (Apr 18, 2025): This is expected behavior due to how environment variables are handled at the process level. When you set an environment variable in PowerShell (or any process), it only affects: The current PowerShell process ($env:MY_VAR) Optionally, the User or Machine registry (via SetEnvironmentVariable) — but changes there only apply to new processes started after the change. Python (or any other script runner) will not see the updated variable unless it's started after the environment is refreshed, which typically means restarting the agent or the host process managing these scripts. Why this happens: Each script runs in its own process context, and environment variables are inherited at process launch — they are not live-synced between processes. Workaround: If you need to pass values between scripts, consider: Using files or a shared temp location Using custom fields (if Tactical RMM) Restarting the agent or script host after setting persistent env vars

kerem commented

2026-03-14 07:07:01 +03:00

Author

Owner

@P6g9YHK6 commented on GitHub (Apr 18, 2025):

i don't think it would be too much to expect that each runtime simply refresh the env vars at each run and should be fairly minimal on resource impact.

using files is not really a good practice for stuff that can fit in ENV.

and not everything should be a custom field when it should be bound to the device and not sensitive to a trmm agent reinstall for exemple.

or i will end up having to make a task to do the workaround of restarting the agent run on each agent on a regular basis and i don't believe this should be the solution to this uniquely "trmm agent" issue.

@P6g9YHK6 commented on GitHub (Apr 18, 2025): i don't think it would be too much to expect that each runtime simply refresh the env vars at each run and should be fairly minimal on resource impact. using files is not really a good practice for stuff that can fit in ENV. and not everything should be a custom field when it should be bound to the device and not sensitive to a trmm agent reinstall for exemple. or i will end up having to make a task to do the workaround of restarting the agent run on each agent on a regular basis and i don't believe this should be the solution to this uniquely "trmm agent" issue.

kerem commented

2026-03-14 07:07:06 +03:00

Author

Owner

@silversword411 commented on GitHub (Apr 22, 2025):

Didn't know about refreshenv maybe an equivalent can be added, or a service restart on install would work around the problem of the agent being a subprocesses with limited environment on first start after install.

@silversword411 commented on GitHub (Apr 22, 2025): Didn't know about `refreshenv` maybe an equivalent can be added, or a service restart on install would work around the problem of the agent being a subprocesses with limited environment on first start after install.