PipedreamHQ / PipedreamHQ/pipedream

QuickBooks

Open
#21,733 0 comments 0 reactions 0 assignees View on GitHub
bug user request
Dominant language
JavaScript
Stars
11.7k
Forks
5.8k
Avg merge
3d 10h
Merged PRs (30d)
102

Description

### 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:
1. Dynamic client registration
2. Authorization / broker grant
3. Token exchange
4. 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

Contributor guide

Open the contributing guide

Research direction

No repository files, tests, or entry points are named. Start with the retained server-side records for the reported authorization attempt and determine whether they identify a stage or non-secret reason; done means providing only that category or a support correlation reference without changing connections.

Written by the indexing model from the issue text.

Assessment

Domain
authentication
Issue type
Bug
Difficulty
5/5
Estimated time
Over a week
Activity status
Active
Clarity
Needs clarification
Newbie friendliness
20/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.