Asterisk AMI action is missing, unknown or permission denied

Freeze the request and session identity

Record server identity, running branch and maintenance release, build and package source, manager username, transport, connection time, client version, exact action and headers, unique ActionID, raw response and optional Message. Redact secrets without removing the fields needed to compare framing.

Distinguish an action absent from a client menu, absent from ListCommands, rejected as unknown, rejected by authorization and accepted but unsuccessful against a target. These symptoms enter the evidence chain at different points.

Check the user-scoped command list

Issue ListCommands through the same authenticated session and retain the complete result. If the action appears, user-visible registration exists at that moment; continue with request syntax, required fields, target objects and the documented response or event sequence.

If it is absent, do not infer a missing module. Confirm the session did not reconnect under another username or host and continue to the administrator-side registry.

Compare the running administrator registry

On the same running instance and time window, use manager show commands and then the bounded manager show command <action> detail. If the CLI inventory contains the action but ListCommands does not, compare the manager account's effective write authorization and the action's privilege class. Avoid granting all as a diagnostic shortcut.

If neither surface contains the action, keep authorization unchanged while checking installed support and registration.

Trace release, package and module registration

Compare the exact installed branch and maintenance release with the current and branch-specific generated action reference. Account for packages that split modules and for runtime module-loader policy. Then verify the owning module's loaded state and registration logs without assuming a file on disk registered its actions.

An action may be added during an Asterisk major line, so a major-only version comparison is insufficient. An older SDK, cached schema or static client allow-list may also hide an action that live inventory exposes.

Validate authorization, framing and parameters

Review the manager user in manager.conf: write permission controls classes of actions, while read permission controls classes of events. Keep event masks and filters separate from action authorization. Validate Header: value framing, the blank-line terminator, exact action name, required fields and target identifiers.

Preserve Response: Success or Response: Error and the optional Message verbatim. Do not parse message text as a universal error code or widen network exposure and privileges merely to make the symptom disappear.

Retest minimally and prove the intended result

Repeat the smallest safe action with a new unique ActionID. If it produces related events, wait for the documented completion boundary and correlate only those messages that carry the transaction identifier. Then verify the target object and operational outcome independently.

Record whether the repair changed runtime registration, manager authorization, request syntax, client discovery or the target itself, and preserve rollback evidence through the deployment's configuration owner. No PBX, module, manager session, request, response, event, channel, packet, media stream or live call was inspected or tested for this diagnostic.

Rule out session identity before changing permissions

The AMI login diagnostic verifies listener, authentication and reconnect boundaries before interpreting a missing action.

Compare exact branch documentation before widening permissions

An action documented only in another branch or omitted from the installed build will not appear through a permission change. Use the version/build diagnostic before changing manager rights.