An empty approval inbox can mean the lookup is wrong. In a public reproduction, an Inngest-backed Mastra agent emitted a pending tool approval, but the suspended-runs endpoint returned no runs. Sending the real run and tool-call identifiers to the approval endpoint produced a 403. The report describes a user trying to approve their own action, not an unauthorized-access incident.
The September 25 fix follows the storage name. Inngest saves its durable loop under inngest:durable-agentic-loop; the relevant lookups expected the core engine’s name. The agent now advertises its loop name for discovery and approval checks. The patch also recognizes the durable approval payload so the listing includes its approval flag and arguments.
Example: a small approval inbox
Mastra is the API provider here; this is an endpoint on an application running its server, not a hosted public-data service. The public route definitions provide GET /api/agents/:agentId/suspended-runs and POST /api/agents/:agentId/approve-tool-call. The latter accepts the selected runId and toolCallId.
A useful example is an editorial assistant that prepares a local note, then waits for a person to approve writing it. An inbox can show the pending tool’s name and arguments instead of inferring unfinished work from a chat transcript. Keep the first prototype to a harmless local write. Show the actual arguments and require an explicit selection before submitting approval.
Copyable agent instruction
In a disposable Mastra application, pin revisions that contain PR #25167
across core, server and the Inngest integration. Build an approval inbox
for one Inngest-backed agent with a harmless local save_note tool marked
requireApproval: true. Use the application's configured authentication.
GET /api/agents/{agentId}/suspended-runs and display each pending tool's
name and args. Do not approve automatically. After I select one, POST
/api/agents/{agentId}/approve-tool-call with its runId and toolCallId.
Verify that no note exists before approval and that the owner can create
it afterward. Under a second test identity, verify the run is absent
from discovery and approval returns 403. Report installed versions and
results; do not relax ownership checks to make the test pass.Access and test caveat
The new integration test uses a real Inngest development server, a separate worker, authenticated resource identities and a mock model. It checks that another identity cannot discover or approve the run, then observes the owner-approved worker’s file output. We inspected this test and the implementation; we did not run that service stack or verify a released package set.
Use your server’s authentication and resource mapping; the test’s bearer-token setup is an example, not a universal credential scheme. Provider calls may cost money if you replace the mock model. A merged changeset does not establish that an older installation contains the repair. The useful acceptance test is two-sided: the right person sees the waiting action, and the wrong person still cannot act on it.