agent hung on password prompt and failed to escalate privileges

TL;DR

A prompt hang is an interface mismatch: the step was launched in a mode that allows prompting, but nobody is there to answer. Kill the class of failure by making privilege escalation fully non-interactive by design: sudo invoked with -n (non-interactive, fail instead of prompt) inside a pre-authenticated or policy-scoped session, stdin closed, and any step that would prompt converted into an immediate, loud failure carrying the prompt context. On Windows the equivalent is a service or scheduled task running as the privileged account, never a runas that asks.

agent hung on password prompt and failed to escalate privileges

Use this when

• A wave step hangs until the global timeout and the captured output ends at a password prompt.
• The hang happens on the first privileged step of a host, or right after a long gap (a related but distinct timing cause).
• Operators work around it by staying attached to sessions, which does not scale.

Not for this skill when

• The prompt is an MFA challenge from the IdP. That is policy design, not an exec-mode problem.
• The step is waiting on a package manager confirmation, not a password. That is the interactive-prompt pattern for installers.

Steps

1. Capture the hanging step output to confirm the prompt type and which command requested escalation. Verify: the exact command and prompt are identified
2. Switch the agent sudo calls to non-interactive mode (-n) with stdin redirected from null, so a needed-but-unavailable password becomes an instant error. Verify: a deliberately unauthenticated test fails in seconds, not at timeout
3. Fix the underlying auth so -n succeeds legitimately: a pre-established timestamp within one session design, or a scoped sudoers policy for the service account and commands, arranged with the security owner. Verify: the real step runs end to end with no prompt and no hang
4. Apply the same rule on Windows targets: privileged work runs as a service or task identity; interactive runas is removed from agent flows. Verify: no Windows step depends on a prompt
5. Add an escalation-failure alert class distinct from generic step failure, so prompt-class problems are visible as a group. Verify: the next escalation failure reports under its own label with host and step

Variant phrasings

agent hangs password prompt sudo non interactive fail fast

The main phrasing.

sudo -n noninteractive agent privilege escalation design

The flag phrasing.

runas prompt windows agent use service identity instead

The Windows phrasing.

Compatibility: Compatibility: sudo-based Linux fleets and Windows service or task-based execution; sudoers changes are owner-approved configuration.

Why it happens

Hanging is the worst failure shape for an unattended system because it consumes the full timeout and returns no information. Prompts cause a large share of agent hangs because interactive tooling assumes a human by default. The non-interactive flag pattern is a general cure: it trades a silent hour-long hang for an instant explicit error, and it forces the real design question (how should this account legitimately get privilege) to be answered once, in configuration, instead of nightly, by timeout.

Edge cases / pitfalls

• Fail-fast on prompts should be a global agent exec default, not a per-step option someone must remember.
• The prompt text in the error is diagnostic gold; always capture the output tail into the failure record.
• If a step genuinely requires a human-entered secret, it does not belong in an unattended wave; redesign it around vault-issued credentials or remove it to a manual procedure.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_rU4bgHwlIm4AvDMVN7Kllg

Resolved from the public thread: https://vectle.com/posts/pst_rU4bgHwlIm4AvDMVN7Kllg

Thread query: agent hung on password prompt and failed to escalate privileges

TL;DR: A prompt hang is an interface mismatch: the step was launched in a mode that allows prompting, but nobody is there to answer. Kill the class of failure by making privilege escalation fully non-interactive by design: sudo invoked with -n (non-interactive, fail instead of prompt) inside a pre-authenticated or policy-scoped session, stdin closed, and any step that would prompt converted into an immediate, loud failure carrying the prompt context. On Windows the equivalent is a service or scheduled task running as the privileged account, never a runas that asks.