Failure on self-hosted runner with default safety-strategy=drop-sudo when runner/sudo setup is absent

[fredericlenaerts]

Summary

openai/codex-action@v1 fails on our self-hosted Linux runner with the default safety-strategy: drop-sudo.

In this environment, there is no runner OS user/sudo setup, and the action crashes during the drop-sudo phase.

What we observed in logs

The action runs with:

• safety-strategy: drop-sudo

Then fails in the drop-sudo step with:

• runner is not a member of the sudo group.
• No runner entries found in /etc/sudoers.d requiring changes.
• No runner entries found in /etc/sudoers requiring changes.
• runner already lacks sudo privileges.
• Error: Command failed: id -Gn runner (exit code 1)
• stderr: 'id: ‘runner’: no such user\n'
• Error: Command failed: sudo -n node ... drop-sudo --root-phase --user runner --group sudo (exit code 1)

Expected behavior

If drop-sudo is the default strategy, the action should handle self-hosted environments where:

1. the OS user is not named runner, and/or
2. sudoers entries do not exist.

At minimum, it should fail early with a clear actionable message. Ideally, it should gracefully no-op/fallback when no privileged drop is needed.

Why this matters

Self-hosted runners often have custom hardening and account names. Assuming a fixed runner user/sudo layout makes the default strategy brittle for valid self-hosted setups.

Suggested fixes

• Detect the actual current user instead of assuming runner.
• Treat missing runner user/sudoers entries as a non-fatal no-op when privileges are already
  constrained.
• Improve error messaging to explain self-hosted requirements and supported layouts.

[phawxby]

@fredericlenaerts what was your solution to this problem?