---
name: reference_gururmm_command_type
description: GuruRMM agent only accepts specific command_type values; an unknown type is silently dropped (looks like a black-hole)
metadata:
  type: reference
---

GuruRMM agent `CommandType` (agent/src/transport/mod.rs) accepts ONLY: `shell`,
`powershell`, `python`, `script`, `claude_task` — plus alias `cmd` → shell
(added 2026-06-12). On Windows: `powershell` runs powershell.exe (UTF-8 output
fixed in-agent, so the old "-OutputEncoding not recognized" quirk is gone);
`shell`/`cmd` runs cmd.exe.

A command with an UNKNOWN `command_type` fails the agent's whole-message serde
parse; pre-2026-06-12 the error was logged-and-ignored and the command was
**silently dropped — no ack, no result** — indistinguishable from a NAT/proxy
black-hole. On 2026-06-12 a `command_type:"cmd"` (no variant then) caused a long
mis-diagnosis (7 multi-AI rounds, packet captures, a pfSense SNAT change) of
"PST agents can't receive commands" — the agents ran `powershell` commands fine
the whole time. The agent now also NAKs an unparseable command (CommandAck +
error CommandResult) so it fails fast instead of black-holing.

**How to apply:** When a dispatched command sits un-acked/never-completes,
FIRST verify `command_type` is one of the valid values before chasing the
network/proxy. Never send a made-up type. See [[reference_gururmm]].
