AWS CLI block drops HOME in Kubernetes, causing “Could not determine home directory”

[mohanrao]

Description

In Kubernetes deployments, the OpenOps AWS CLI action can fail before making any AWS API call because it spawns aws with a reduced child-process environment that omits HOME. In non-root containers, AWS CLI v2 may require HOME during startup (awscli/telemetry.py → pathlib.home()), which causes the process to crash with RuntimeError: Could not determine home directory.

Expected Behavior

AWS CLI actions should execute normally in Kubernetes/non-root containers and either:

• return command output, or
• fail with a real AWS authentication/authorization/API error

They should not crash during AWS CLI startup because HOME is missing from the spawned process environment.

Actual Behavior

The AWS CLI process crashes immediately with:

RuntimeError: Could not determine home directory.

Relevant traceback excerpt:

File "awscli/telemetry.py", line 31, in <module>
File "pathlib/_abc.py", line 758, in home
File "pathlib/_local.py", line 808, in expanduser
RuntimeError: Could not determine home directory.

This happens before the AWS command is actually executed.

Steps to Reproduce

1. Deploy OpenOps in Kubernetes with the engine running as a non-root user.
2. Run an AWS CLI action such as:

   ec2 describe-regions --region us-east-1 --all-regions --no-cli-pager --output json --query "Regions[?OptInStatus=='opt-in-not-required' || OptInStatus=='opted-in'].RegionName"

3. Observe that the AWS CLI child process fails with Could not determine home directory.

Screenshots or logs, if applicable

Error observed in OpenOps logs:

An error occurred while running AWS CLI command: Error: Failed to run the aws command: 'ec2 describe-regions --region us-east-1 --all-regions --no-cli-pager --output json --query "Regions[?OptInStatus=='opt-in-not-required' || OptInStatus=='opted-in'].RegionName"'. Error: {"exitCode":1,"stdOut":"","stdError":"Traceback (most recent call last):\n  File \"aws.py\", line 19, in <module>\n  File \"<frozen importlib._bootstrap>\", line 1360, in _find_and_load\n  File \"<frozen importlib._bootstrap>\", line 1331, in _find_and_load_unlocked\n  File \"<frozen importlib._bootstrap>\", line 935, in _load_unlocked\n  File \"PyInstaller/loader/pyimod02_importers.py\", line 384, in exec_module\n  File \"awscli/clidriver.py\", line 78, in <module>\n  File \"<frozen importlib._bootstrap>\", line 1360, in _find_and_load\n  File \"<frozen importlib._bootstrap>\", line 1331, in _find_and_load_unlocked\n  File \"<frozen importlib._bootstrap>\", line 935, in _load_unlocked\n  File \"PyInstaller/loader/pyimod02_importers.py\", line 384, in exec_module\n  File \"awscli/telemetry.py\", line 31, in <module>\n  File \"pathlib/_abc.py\", line 758, in home\n  File \"pathlib/_local.py\", line 808, in expanduser\nRuntimeError: Could not determine home directory.\n[PYI-73:ERROR] Failed to execute script 'aws' due to unhandled exception!"}

Root cause identified in deployed code:

• The AWS CLI block builds a fresh child env with AWS_DEFAULT_REGION and PATH, but does not preserve HOME.
• That env is then passed to execFile().

Recommended fix:

const envVars = {
  AWS_DEFAULT_REGION: region,
  PATH: process.env['PATH'] ?? '',
};

if (process.env['HOME']) {
  envVars.HOME = process.env['HOME'];
}

Your environment

Release version: 0.6.23
Operating System: Kubernetes on AWS EKS
Browser: N/A
Additional information:

• Engine running as non-root user (runAsUser: 1000)
• Issue reproduced in Kubernetes deployment
• Confirmed that preserving/restoring HOME prevents the startup crash and allows the command to proceed to normal AWS authorization behavior

Additional Context

I verified this live in the deployed engine container:

• If aws is spawned as a child process with HOME removed, it reproduces the exact traceback above.
• If the same child process runs with valid HOME handling, the home-directory crash disappears and the command proceeds to actual AWS auth evaluation.

So this appears to be a real environment propagation bug in the AWS CLI action path, not an AWS permission or command syntax issue.

[linear]

OPS-4060

[mohanrao]

@maor-rozenfeld actually this problem exists for all commands also the right fix is here

openops/packages/openops/src/lib/command-wrapper.ts

Line 29 in 999e1d7

env: envVariables,

// Current — replaces entire env, loses HOME
const options: ExecFileOptions = {
  env: envVariables,
};

// Fix — inherits pod env first, then overlays any custom vars
const options: ExecFileOptions = {
  env: { ...process.env, ...envVariables },
};