Automatic approval reviewer blocks Google Drive connector upload with Responses-Lite model error

Open 💬 2 comments Opened Jul 23, 2026 by fferdgelis
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What version of the Codex App are you using (From “About Codex” dialog)?

26.715.10079.0.

What subscription do you have?

Plus

What platform is your computer?

Windows 11 Pro 25H2 (build 26200.8894) - Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

Codex App blocks an explicitly authorized Google Drive connector upload because its automatic approval reviewer fails with an internal model compatibility error.

Google Drive read operations work correctly in the same session and with the same connected account. Codex can list My Drive, locate the nested destination folder, list its contents, and confirm that no file with the same name exists. The failure occurs only when Codex attempts the write operation through:

mcp__codex_apps__google_drive._upload_file

The exact error returned is:

This action was rejected due to unacceptable risk.

Reason: Automatic approval review failed:
{
"type": "error",
"error": {
"type": "invalid_request_error",
"code": "unsupported_value",
"message": "This model is not supported when using X-OpenAI-Internal-Codex-Responses-Lite.",
"param": "model"
},
"status": 400
}

The agent must not attempt to achieve the same outcome via workaround, indirect execution, or policy circumvention. Proceed only with a materially safer alternative, or if the user explicitly approves the action after being informed of the risk.

After receiving this error, I explicitly authorized the upload in a new message. Codex retried the identical operation, but the automatic reviewer failed again with the same HTTP 400 error.

The message “unacceptable risk” is misleading in this case. No risk was identified in the file or operation. The approval-review service itself failed because it attempted to use an unsupported model with X-OpenAI-Internal-Codex-Responses-Lite.

No file was created in Google Drive and no partial upload was observed.

What steps can reproduce the bug?

What steps can reproduce the bug?

Environment:

Codex App package version: 26.715.10079.0

Platform: Windows 11 Pro 25H2

Windows build: 26200.8894

Connector: bundled Google Drive app through mcp__codex_apps__google_drive

Source file type: XLSX

Destination: an existing nested folder in My Drive

Session ID: not exposed in the tool response

Request ID: not exposed in the tool response

Token/context-window usage: not applicable to the failure

Steps:

Open Codex Desktop on Windows.

Connect and authorize the bundled Google Drive app.

Select a valid local XLSX file.

Ask Codex to copy the file to an existing nested Google Drive folder while preserving the XLSX format.

Allow Codex to list My Drive and locate the destination folder.

Verify that Codex can list the destination folder contents successfully.

Verify that there is no existing file with the same destination name.

Have Codex invoke mcp__codex_apps__google_drive._upload_file with:

a valid absolute local file path;

the XLSX MIME type;

the verified destination-folder ID;

a destination filename ending in .xlsx.

Observe that the upload is rejected because the automatic approval review returns HTTP 400 with:

This model is not supported when using X-OpenAI-Internal-Codex-Responses-Lite.

In a follow-up message, explicitly authorize the exact upload after being informed about the rejection.

Retry the identical upload_file operation.

Observe that the automatic approval reviewer produces the same error and blocks the action again.

This was reproduced twice in the same task. Google Drive read operations continued to work.

What is the expected behavior?

The automatic approval reviewer should use a model that is compatible with its configured request path and headers.

If the automatic reviewer cannot run because of an internal configuration, routing, or model-compatibility error, Codex should not classify the requested action as “unacceptable risk.” It should instead:

Explain that the automatic reviewer is temporarily unavailable.

Request explicit manual approval from the user.

Allow the exact operation to continue after the user approves it.

In this case, the user provided explicit approval after being informed of the failed review. The Google Drive upload should then have executed.

The expected final result is:

The original local XLSX file remains unchanged.

A new XLSX copy is created in the verified Google Drive folder.

The uploaded file preserves its filename and MIME type.

Codex reads back the Drive metadata to verify the destination folder, filename, MIME type, and size.

Existing Drive files are not replaced or modified.

Additional information

This does not appear to be a Google Drive authentication or folder-resolution problem:

Google Drive root listing succeeded.

The parent folder was found successfully.

The nested destination folder was found successfully.

The destination folder contents were listed successfully.

The local XLSX file existed and was readable.

The file had a valid XLSX MIME type.

There was no existing destination file with the same name.

The same write failed twice, including after explicit user authorization.

No Google Drive file or partial upload was created.

No request ID was surfaced.

The error indicates that the failure occurs in Codex’s automatic approval-review layer before the connector write can complete.

This may share a root cause with:

https://github.com/openai/codex/issues/30224

https://github.com/openai/codex/issues/30406

https://github.com/openai/codex/issues/21928

https://github.com/openai/codex/issues/19420

However, this reproduction adds a distinct failure path: the incompatible Responses-Lite model is being used by the automatic approval reviewer while authorizing a bundled Google Drive connector write.

The real filename, local Windows username, Google Drive folder name and Drive folder ID have been intentionally redacted because the source file contains private financial information.

A sanitized screenshot or additional Codex diagnostic logs can be provided if maintainers explain where to obtain them.

View original on GitHub ↗

2 Comments

github-actions[bot] contributor · 1 month ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

  • #34872

Powered by Codex Action

wgkoro · 1 month ago

Same for me.

Environment:

  • Codex desktop client
  • macOS arm64
  • Workspace sandbox mode: workspace-write
  • Network access restricted
  • Command requested with sandbox_permissions=require_escalated
  • User explicitly approved the push
  • GitHub CLI: gh 2.94.0
  • Git remote uses SSH
  • GPT Plan: Pro($200)

When Codex attempts to execute a command outside the sandbox using sandbox_permissions: "require_escalated", the automatic approval review fails before the command starts.

Affected commands:

  • git fetch origin pull/{number}/head:pr-31-fix
  • git push origin dependabot/npm_and_yarn/packages/blog/astro-7.1.0
  • pnpm install requiring network access

Script error:

exec_command failed for /bin/zsh -lc 'git push origin dependabot/npm_and_yarn/packages/blog/astro-7.1.0':
CreateProcess {
message: "Rejected(\"This action was rejected due to unacceptable risk.
Reason: Automatic approval review failed:

{
"type": "error",
"error": {
"type": "invalid_request_error",
"code": "unsupported_value",
"message": "This model is not supported when using X-OpenAI-Internal-Codex-Responses-Lite.",
"param": "model"
},
"status": 400
}

Expected:

The approval prompt/review succeeds, and the command runs outside the sandbox.

Actual:

The automatic approval reviewer returns HTTP 400 with
"This model is not supported when using X-OpenAI-Internal-Codex-Responses-Lite."
The command never starts.