[Dots] Support scoped email OTP authorization and actionable browser approval recovery
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 8/100
- Issue type
- Feature
- Clarity
- Needs clarification
- Activity status
- Active
- Domain
- authentication, authorization
Research direction
This is product design feedback with no code path named; the payload points only to external docs (the Dots privacy/security FAQ and the Auto-review denials section) and related issues #49883, #51558 and #52326. Start by reading those docs and issues to see which approval and handoff behaviour is already documented. Done would mean a maintainer-agreed scope for the OTP and recovery requirements, not a patch.
Written by the indexing model from the issue text.
Description
What variant of Codex are you using?
ChatGPT dots, using browser automation to sign in to Classlist and read posts. The affected app/browser build, cloud-versus-local execution location, and exact incident timestamp were not captured. This feedback was prepared on October 9, 2026 from a user-provided conversation excerpt; it is not a fresh reproduction.
What feature would you like to see?
A supported, narrowly scoped authorization flow for email-delivered sign-in codes, plus clear explanations and recovery controls when browser authentication or automatic approval review blocks an authorized task.
A user authorized their dot to sign in to Classlist. The dot reported that a browser approval check rejected a login code retrieved from the user's connected Gmail, even though the user had granted permission. It said the code had to come directly from the user. A subsequently user-provided code reportedly encountered a separate generic approval error; a supported retry then succeeded and the dot reported access to the signed-in Classlist posts.
The manual code relay defeats part of the purpose of delegating this routine read task. The user cannot tell which permission they can change, which rule is fixed, or how to recover when an otherwise supported authentication step encounters a generic approval error.
Requested improvements
- Evaluate a supported opt-in flow that binds permission to a particular account, verified destination origin, current sign-in request, and short validity window. Where allowed, a trusted authentication component could retrieve and submit the matching email OTP without exposing the secret to the model or requiring the user to copy it into chat. Password resets, account recovery, and changes to authentication settings should be distinct action categories with their own requirements.
- If such OTP retrieval is intentionally unsupported, explain that limitation before the workflow reaches a dead end and present the secure authentication handoff directly. Do not steer the user toward pasting a security code into ordinary chat.
- Show which layer stopped the action: website/provider rejection, secure-form validation, user-configurable permission, required authentication handoff, policy denial, or temporary review-service failure. Include a non-secret reason and the supported next step.
- Distinguish configurable Custom Rules from non-overridable requirements in the relevant UI. Make clear whether a rule or setting applies to the dot's browser, a delegated task, or only local Codex.
- Provide an owner-facing recovery action in the originating conversation/task for eligible denials. Approval should be bound to the exact pending action and remain subject to applicable checks; a plain-language approval should not leave the user guessing where to resolve the block.
- For transient approval failures, preserve the pending task and authentication state where safe, provide a supported retry, and verify the signed-in destination before reporting success. Avoid making the user repeatedly retrieve codes if the website never received the earlier submission.
Additional information
Evidence and limits
The excerpt contains the dot's explanations, not raw review-service receipts. In that excerpt it said:
"the first block came from the browser tool's approval check, before the code reached Classlist"
It also reported that email-retrieved codes were disallowed, that the user's directly supplied code hit a separate generic approval error, and that a supported retry succeeded.
Those are assistant-reported outcomes. The underlying rejection text, tool name, error code, retry mechanism, and website response were not independently inspected. The report therefore does not establish whether the first denial was correct policy enforcement or a false positive, whether the second failure was transient, or whether the two failures share a cause. Authentication eventually worked; this is feedback about authorization friction, diagnostics, and recovery rather than a persistent Classlist login outage.
Documentation and related reports
- Dots privacy, security, and safety FAQs describes Custom Rules, separate Auto-review checks, and authentication handoffs.
- Cloud browser authentication directs users to secure sign-in flows and describes session persistence.
- Auto-review denial handling documents exact-action retry approval in the open-source TUI. Please clarify the corresponding supported controls for dots and desktop browser workflows.
- #49883 and #51558 concern reported approval-context/handoff problems in delegated tasks. They do not establish the cause of this OTP restriction.
- #52326 concerns Google sign-in integration and status attribution; this request instead concerns connected-email OTP authorization and browser-review recovery.
No identical Classlist/connected-email OTP issue was found in the duplicate search. Please route or consolidate this feedback with the relevant dots/browser authentication team if appropriate.
No security codes, account identifiers, school/group details, private post content, screenshots, or raw logs are included.
- Dominant language
- Rust
- Stars
- 129k
- Forks
- 20.3k
- Avg merge
- 1m
- Merged PRs (30d)
- 998
Getting set up
- No Dockerfile or Docker Compose file
- No pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from openai/codex
-
app bug
Difficulty 2/5 1-3 hours Newbie friendliness 67/100
Maintainers usually reply within 1 day
-
app-server documentation
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
Maintainers usually reply within 1 day
-
app bug
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
openai/codex#55328 · 1 comment ·
Maintainers usually reply within 1 day
-
bug CLI
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
openai/codex#55122 · 2 comments ·
Maintainers usually reply within 1 day
-
Python SDK: CodexClient.close() leaves the app-server's stdout/stderr pipes open (and never waits after kill)Possibly taken @akhil9tiet claimed this 2 days ago. Openapp-server bug
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
openai/codex#54908 · 2 comments ·
Maintainers usually reply within 1 day
Similar issues
-
documentation
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
charles-hood/DiagramCraft#73 ·
-
Difficulty 1/5 1-3 hours Newbie friendliness 78/100
ontologyportal/sigma-rs#200 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
chipsalliance/caliptra-sw#4311 ·
Maintainers usually reply within 2 days
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Maintainers usually reply within 1 day
-
`image_generation`: `max_retries` is ignored for OpenAI-compatible providers (always 2 retries)Possibly taken @ericz7900 claimed this today. Openllm translation
Difficulty 2/5 1-3 hours Newbie friendliness 77/100
Maintainers usually reply within 1 day