On Grok Bot iOS, re-authorizing the Todoist connector opened app.todoist.com and showed JSON: error invalid_request, error_description “code_challenge is required for public clients”. Retrying the same reconnect immediately afterward succeeded. Intermittent first-attempt OAuth/PKCE failure on the official Todoist plugin.
Steps to Reproduce
On Grok Bot iOS, open a Todoist connector that needs re-auth.
That error page is served by Todoist’s authorization server, not by Grok Bot. On our side, the Todoist sign-in link we generate always includes the PKCE code_challenge, including on the attempt that failed. So it looks like the parameter is being dropped somewhere between opening the page and reaching Todoist’s authorize endpoint.
My best guess: it happens when Todoist first needs to sign you in (or refresh its web session) and then returns to the authorization page without those parameters. That would explain why the immediate retry succeeded.
Does the error only occur on the attempt where Todoist asks you to sign in?
Does the retry go straight to the permission screen?
@Colin thanks — answering your questions and sharing the Todoist close-out.
Retry: Yes — the successful retry went straight to the permission / allow screen (no Todoist login gate on that attempt).
Failed attempt / sign-in: We don’t have a clear memory of whether the failing attempt first asked for a Todoist web sign-in before the code_challenge JSON error. Fail was in the Grok Bot iOS in-app webview on app.todoist.com at 2026-09-07 08:41:37 Eastern (EDT) with invalid_request / “code_challenge is required for public clients”. Authorize URL query string was a Gap (not in Safari history).
Vendor (Todoist #942781): Melis closed the ticket after we sent the timestamp. Their note: the omission is on Cursor’s connector side, documented with Todoist eng. From our side that Zendesk ticket can stay closed.
Happy to capture another repro with authorize-URL logging if useful. Todoist is connected again on our side; still tracking here for the intermittent first-attempt drop.
Update from Cursor support (Michael, same SendFeedback thread as Sam T-F62889)
Every sign-in link they generated — including the failed attempt — included code_challenge. The error page was Todoist’s authorize page, so the param was likely dropped between opening the page and Todoist receiving the request. That matches the intermittent first-fail / immediate retry straight to Allow we saw.
They’re tracking this as a reconnect issue in the iOS in-app flow. Melis/Todoist’s note that a missing code_challenge looks connector-side was useful context for them.
Guidance if it happens again: retry connect in the app (worked last time); if it keeps failing, connect Todoist from desktop; a screenshot of the authorize-page address bar would help.
Todoist is connected again on our side; still watching here.
