When an HttpError occurs in Google Tasks tools, the error handler now checks
the HTTP status code before suggesting re-authentication. Re-auth messages are
only shown for 401 (Unauthorized) and 403 (Forbidden) errors.
This prevents misleading re-authentication suggestions for non-auth errors like
400 (Bad Request) with malformed arguments, allowing the LLM to focus on the
actual root cause instead of being misdirected by incorrect auth guidance.
The fix applies to both CLI mode (stdio legacy oauth) and MCP mode (OAuth 2.1).
Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
Addresses CodeRabbit Review 4 nitpick: the test validates
parse_permissions_arg() so it belongs with that test class.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Addresses CodeRabbit Review 3 nitpick: verify TASKS_READONLY_SCOPE is
present at full level, confirming cumulative scope expansion.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
- Add docstrings to test methods for coverage threshold
- Add autouse fixture to reset permission state between tests
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Addresses CodeRabbit review — clear_completed is destructive and should
be blocked alongside delete at the manage permission level.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
The consolidated manage_task tool bundles create/update/delete/move into a
single tool, making it impossible to deny just the delete action via tool
tiers or scope-based filtering.
This adds:
- A `manage` permission level for tasks (between readonly and full)
- A SERVICE_DENIED_ACTIONS registry mapping (service, level) to denied actions
- An is_action_denied() helper that tools call before executing actions
- Guards in manage_task and manage_task_list that reject denied actions
Usage: --permissions tasks:manage
Allows create, update, move. Denies delete.
tasks:full remains unchanged (all actions allowed).
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
When `create_oauth_flow()` is called without an explicit `code_verifier`
(i.e. during the initial auth flow in `start_auth_flow()`), the function
never sets `autogenerate_code_verifier=True` on the Flow constructor.
oauthlib 3.2+ automatically adds `code_challenge` to the authorization
URL at the session level, so Google expects a matching `code_verifier`
during the token exchange. However, since `Flow.code_verifier` remains
`None`, that `None` gets stored in the session store and later passed
back during the callback — causing Google to reject the token exchange
with `(invalid_grant) Missing code verifier`.
The fix adds `autogenerate_code_verifier=True` in the else branch so
the Flow object generates and exposes a proper PKCE code verifier that
gets stored and reused during the callback token exchange.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
