Linux Managed Run Command remains Pending after failed deletion despite prior successful execution

Question

We need a supported read-only way to determine whether an old Linux Managed Run Command can still execute, before recovering a separate application coordination lock. We are not requesting a retry or deletion as a diagnostic.

Observed chronology (UTC):

• 13 September 2026 08:37:44: exact command execution Succeeded, exit 0, start/end recorded. The bounded readiness probe reported completion and its own lock release.
• 13 September 09:44:23: deletion failed with ResourceOperationFailure / InternalExecutionError. No deletion retry.
• Guest handler log shows disable/end at 09:44:25, uninstall/data-directory removal on 21 September, then install-only events on 23 and 26 September. No later enable for the exact resource was found in the retained log, whose coverage ends on 18 October at 15:44:41 UTC. This is not proof beyond that coverage.
• Current expanded resource GET reports provisioningState Succeeded, executionState Pending, exitCode 0, with no execution start/end timestamps. Source script hash matches the original. asyncExecution=false; timeoutInSeconds=60.
• A bounded privileged inspection of Managed handler version 1.3.28 finds the exact command's .0.settings file, but no matching per-command status or processed-sequence file in the inspected handler root/status/data root. Settings payloads were deliberately not read or shared.

An old successful execution and absent later enable events do not prove the current provider request cannot be queued. We have not altered handler files, deleted the command again, changed schedules, or replayed the script during this investigation.

Questions:

1. Which supported provider/guest-agent state establishes the current desired operation and whether this exact resource has queued or resumable execution?
2. How should the retained settings file with missing status/processed-sequence state be interpreted after uninstall/reinstall?
3. Can Microsoft reconcile the failed deletion and current Pending state without rerunning the script or using deletion as a cancellation test?

Exact resource and correlation IDs are retained for private support. No credentials, settings payloads, business outputs or tenant identifiers are included here.

This is distinct from my earlier question about delayed provisioning success (https://learn.microsoft.com/en-us/answers/questions/6040878/linux-managed-run-command-approximately-five-minut); we have not established that they share a cause.