Google Drive plugin requires broad all-files read/write access to read one Doc

What version of the Codex App are you using?

26.715.31251

What subscription do you have?

Not specified.

What platform is your computer?

macOS (Apple Silicon).

What issue are you seeing?

Installing and authorizing the OpenAI Google Drive plugin in Codex required granting broad access to read, write, and download files across the user's entire Google Drive, even though the immediate task was only to read one Google Doc provided by URL.

This is an unexpectedly broad permission boundary for a narrow, read-only workflow. It creates a material trust and adoption problem: users must authorize access far beyond the file and operation they requested before Codex can read a single document.

No private file IDs, titles, document contents, or organization data are included in this report.

What steps can reproduce the bug?

1. In Codex Desktop, ask Codex to read a single Google Doc by URL.
2. When the document is not publicly accessible, install the OpenAI Google Drive plugin.
3. Start the Google authorization flow.
4. Observe that the requested authorization covers broad read/write/download access across Google Drive rather than read-only access to the selected document (or a user-selected set of files).
5. Complete authorization and observe that the single document can then be read.

What is the expected behavior?

For a request to read one Google Doc, Codex should support a least-privilege authorization path, ideally one of:

• permission limited to a user-selected file;
• a Google Picker flow that grants access only to selected files;
• a read-only scope when the requested operation is read-only; or
• clearly separated read and write authorization levels, with escalation only when the user asks Codex to modify or create Drive content.

The consent UI should also explain why each scope is needed and make the effective access boundary unmistakable before authorization.

Additional information

This report concerns the plugin authorization and permission UX, not the contents of the document being accessed. The broad scope was encountered during a normal single-document read workflow.