Google Drive connector: connected/visible, intermittent empty search results, and pre-execution write failures

ChatGPT Bugs
1

Google Drive connector: connected/visible, intermittent empty search results, and pre-execution write failures

Environment: Normal ChatGPT conversation in the native iOS/iPadOS app on an iPad—not a custom GPT, agent flow, or scheduled automation.

Incident dates: September 12–13, 2026

Summary

Google Drive was shown as installed, enabled, and connected in ChatGPT, but Drive discovery intermittently returned no files despite known accessible files. During the same period, routine Google Docs writes repeatedly failed before reaching Google Drive. This workflow had worked reliably for weeks before September 12.

This was not a permanent authorization failure: later read-only searches returned multiple accessible files, a disposable test-document write succeeded, and a same-document replaceAllText control succeeded. Routine staging writes nevertheless continued to fail intermittently, sometimes succeeding unchanged on a later retry.

Observed symptoms

  • September 12: Google_Drive.batch_update_document calls using Google Docs replaceAllText repeatedly failed before execution with: “Could not parse args as JSON.” A minimal ASCII-only retry and disconnect/reconnect did not help. No document change occurred.
  • September 13: Google Drive appeared installed and enabled, while another connection/permission status reported not_installed. Changing permission to Allow all actions / full_access did not resolve the substantive write failure.
  • September 13: Broad Drive discovery and searches for known existing items returned no files while Drive remained visible as connected.
  • September 13: A staging-journal replaceAllText write was blocked before connector execution with: “This tool call was blocked by OpenAI’s safety checks. Please double check what you are sending.”
  • Using the same document, marker, and request structure with a short TEST payload succeeded and returned occurrencesChanged: 1. A disposable Google Doc write also succeeded.
  • A routine write initially received the safety-check block, a same-document TEST succeeded, and a later retry of the routine write succeeded.
  • A subsequent read-only Drive search returned multiple accessible files, confirming that the earlier zero-file result was intermittent.

Affected actions included routine health check-ins, planned/completed rehabilitation logging, organizer updates, and staging-journal appends. Private values, filenames, document IDs, URLs, and file contents are omitted.

Smallest useful reproduction

Drive search

  1. In a normal ChatGPT chat in the native iOS/iPadOS app, confirm Google Drive appears connected.
  2. Ask: “Search my connected Google Drive for any accessible files. Read-only; do not change anything.”
  3. Repeat using the title of a known existing file.
  4. Intermittent result: no files are returned. A later retry may return them.

Google Docs write

  1. Add a unique marker such as [[APPEND_MARKER]] to a disposable Google Doc.
  2. Call Google_Drive.batch_update_document with one replaceAllText request, replacing the marker with TEST followed by the same marker.
  3. Repeat against the same document and marker with the same request shape, changing only the replacement text to a short structured routine-entry payload with all values redacted.
  4. Intermittent result: the request is blocked before connector execution by the safety-check message, fails with the JSON-parsing message, or succeeds only on a later unchanged retry.

Troubleshooting completed

  • Reproduced in a normal ChatGPT conversation.
  • Disconnected, reinstalled, and reconnected Google Drive.
  • Changed permission to Allow all actions / full_access.
  • Re-entered source data from scratch.
  • Retried with minimal ASCII-only text.
  • Tested a disposable document and short TEST payload.
  • Compared control and routine payloads using the same document, marker, and request structure.

Expected behavior

When Drive is shown as connected, searches should consistently return authorized files. A syntactically valid replaceAllText request should either execute and return a Google API result or return a stable, actionable error. Equivalent request shapes should not alternate among empty search results, JSON-parsing failures, safety-check

2

New Tests

The isolation test itself has now hit the same stateful block.

What happened:

  1. Fresh document #1, neutral text → succeeded
  2. Fresh document #2, simple envelope → succeeded
  3. Attempt to create fresh document #3 titled with “Health Destination” → blocked by OpenAI safety checks
  4. Immediate retry with a completely neutral title, Connector Isolation Test 3 → also blocked

That means the block is not reliably tied to the document contents at all. After a safety rejection, even a neutral create_file operation can become blocked in the same session.

So the stronger working hypothesis is now:

The safety layer is applying some session- or sequence-level state after a flagged tool call, rather than evaluating each Drive action independently.

That explains why our earlier experiments produced apparently contradictory results.

3

I’m seeing a materially similar issue and wanted to add an independent data point.

My Google Drive connector problems also began around 12 September 2026. I’m seeing the same exact error:

“This tool call was blocked by OpenAI’s safety checks. Please double check what you are sending.”

In my case, the blocked operation does not reach Google Drive. The behaviour is intermittent: harmless Drive operations can succeed, while other benign writes are blocked, and similar operations can produce different results between conversations/retries.

I use Drive as the transport for a personal local workflow, so my environment is different from yours and I’m not claiming we necessarily have the same root cause. But the timing, pre-dispatch safety error, intermittent successes, and apparent session sensitivity look notably similar.

I reported my case to OpenAI Support and also posted a separate report here, which auto-closed after 24 hours:
“Open AI safety checks blocking benign file writes to Google Drive folders”

I’ll also send your report to Support as independent corroborating evidence. Hopefully the two reports help narrow down whether this is a broader connector/tool-call safety regression.

For reference, my earlier report on this forum is titled:

“OpenAI safety checks blocking benign file writes to Google Drive folders”

There is also an earlier related thread titled:

“ChatGPT app MCP tool calls blocked by OpenAI safety checks before reaching MCP server”

That earlier discussion includes OpenAI Support acknowledging cases where legitimate tool calls were incorrectly blocked before reaching the MCP server.

4

I’m having similar issues with a learning system I’ve been developing for our team that works across projects and chats. Some days are better than others but I feel like I’ve been constantly debugging these blocks and can’t figure out any patterns with it to be able to fix it reliably. Sometimes, just during a test, without taking any action, it just magically starts working across the system for me and the other users.