App
QuickBooks
Summary:
MCP authorization returned “access denied” after final Authorize
Details:
We are using Hermes Agent 0.20.1 (2026.8.13) with Pipedream MCP at https://mcp.pipedream.net/v2 through the documented remote/SSH paste-back flow.
At approximately 2026-08-22 02:35 UTC, the MCP authorization client showed exactly one selected app: production QuickBooks. The owner clicked the single final Authorize control, the browser reached the expected unreachable loopback page, and the complete redirect was pasted directly into the still-live Hermes prompt.
The owner then observed the sanitized phrase “access denied.” We did not retain the redirect, authorization code, state, PKCE values, client identifiers, tokens, raw terminal output, or response bodies.
What we can establish:
- Authorization reached the final Pipedream Authorize action.
- Failure occurred before proven local token persistence or MCP initialization.
- Whether token exchange started is unknown.
- No MCP tools/list, QuickBooks provider tool, or provider-data call completed.
- The local client was rolled back and remains disabled.
- Existing provider Connected accounts were not disconnected, revoked, or changed.
Could you classify the retained server-side stage, if available, as:
- Dynamic client registration
- Authorization / broker grant
- Token exchange
- No retained server-side evidence
Please provide only a non-secret reason category or support correlation reference. We are trying to distinguish an OAuth authorization-response denial from client/account policy, state validation, or token-exchange rejection before making another attempt.
We are not requesting any account, grant, token, or connection change. Please do not disconnect or revoke the existing QuickBooks or Google Business Profile Connected accounts.
Screenshots:
No screenshots included
App
QuickBooks
Summary:
MCP authorization returned “access denied” after final Authorize
Details:
We are using Hermes Agent 0.20.1 (2026.8.13) with Pipedream MCP at https://mcp.pipedream.net/v2 through the documented remote/SSH paste-back flow.
At approximately 2026-08-22 02:35 UTC, the MCP authorization client showed exactly one selected app: production QuickBooks. The owner clicked the single final Authorize control, the browser reached the expected unreachable loopback page, and the complete redirect was pasted directly into the still-live Hermes prompt.
The owner then observed the sanitized phrase “access denied.” We did not retain the redirect, authorization code, state, PKCE values, client identifiers, tokens, raw terminal output, or response bodies.
What we can establish:
Could you classify the retained server-side stage, if available, as:
Please provide only a non-secret reason category or support correlation reference. We are trying to distinguish an OAuth authorization-response denial from client/account policy, state validation, or token-exchange rejection before making another attempt.
We are not requesting any account, grant, token, or connection change. Please do not disconnect or revoke the existing QuickBooks or Google Business Profile Connected accounts.
Screenshots:
No screenshots included