The `Reason` field is not propagated to the approval request payload. When an account is protected by an approval policy, `HandleApprovalWorkflow` calls `accessParams.ToApprovalRequestData(durationStr)`, which omits the user's stated reason entirely — approvers and audit logs for the approval workflow will never see why access was requested, defeating a core purpose of the new feature.

The MFA flow is bypassed when an account requires both a reason and MFA. In `CallPAMAccessWithMFA`, after the user provides a reason (PAM_REASON_REQUIRED branch), the retry calls `api.CallPAMAccess` directly and returns any error raw — so if the server then responds with SESSION_MFA_REQUIRED, the CLI returns that error to the user instead of completing the MFA flow. Any account that enforces both a reason policy and MFA will be inaccessible via the interactive prompt flow; the fix is to call `Ca

When a user runs any PAM command interactively without `--reason`, `resolveReason()` eagerly prompts for an optional reason upfront; if the user presses Enter to skip, an empty reason is sent to the API. If the account policy mandates a reason, the server returns `PAM_REASON_REQUIRED` and `CallPAMAccessWithMFA` then prompts a second time with a mandatory "Reason for access" prompt — the user is asked the same question twice with no explanation for why the first answer was insufficient.