[ChatGPT Web][GitHub] User-authorized file update repeatedly blocked by safety check

Summary

ChatGPT Web can successfully read a user-authorized GitHub repository through the connected GitHub integration, but an explicitly authorized file update is then rejected by an internal safety check. This creates a false-positive write block in a workflow whose allowed write target is already narrowly constrained by the user.

This report is not based on one isolated GitHub failure. The user has spent weeks repeatedly simplifying and migrating the persistence layer to eliminate suspected causes. The same core problem — ChatGPT completing work but failing to persist it reliably — survived Google Docs splitting, Markdown conversion, Drive removal, GitHub migration, per-task file isolation, prompt reduction, and explicit write-path restrictions.

Visual summary of the troubleshooting journey

flowchart LR
    A["Google Docs<br/>long research archive"] -->|"Maybe the document is too long?"| B["Split into<br/>multiple date-range docs"]
    B -->|"Still failing"| C["Shorten prompts<br/>and isolate roles"]
    C -->|"Maybe Docs structure is the problem?"| D["Convert to<br/>plain Markdown"]
    D -->|"Maybe Drive is the problem?"| E["Move away from<br/>Google Drive"]
    E --> F["GitHub<br/>one repo / one branch"]
    F --> G["One writable file per role<br/>latest blob SHA<br/>pre-write re-read<br/>post-write verify"]
    G -->|"Research completes"| H["update_file"]
    H -->|"blocked"| X["SAFETY CHECK"]

    classDef tried fill:#e8f5e9,stroke:#2e7d32,color:#1b5e20;
    classDef blocked fill:#ffebee,stroke:#c62828,color:#b71c1c,stroke-width:3px;
    class A,B,C,D,E,F,G,H tried;
    class X blocked;

Researcher status: (╥﹏╥) “I kept simplifying the workflow because I assumed I was doing something wrong. At this point the research finishes, the authorization is explicit, the file scope is minimal, and the last step is still blocked.”

The slightly humorous diagram is intentional, but the underlying issue is serious: every migration was an attempt to eliminate another plausible user-side cause.

Product / surface

ChatGPT Web
Scheduled / recurring ChatGPT workflow
Connected GitHub account
Previously: Google Docs / Google Drive persistence
Currently: GitHub repository read + Markdown file update workflow

Full history / why this is not a one-off

1. Original workflow: long-running scheduled research written into Google Docs

The user runs several long-running scheduled research workflows (S1-S5). These workflows are expected to do real research work and continuously persist their output into shared documents, rather than leaving the result only in chat.

The original persistence layer was Google Docs / Google Drive. Over time, recurring failures appeared during reads and writes, including:

Google Docs read/write failures
INVALID_ARGUMENT (400) errors involving field masks
failures to locate expected heading structures such as HEADING_2 / HEADING_3
messages saying the document body could not be located safely for insertion
runs that completed reasoning but failed before persistence
scheduled tasks that sometimes stopped or behaved as if persistence failure meant the research step itself had failed

At this stage, the user did not assume the platform was definitely at fault. They repeatedly changed their own workflow to remove plausible causes.

2. Suspected cause: Google Docs became too long

One hypothesis was that the Google Docs files had simply become too large or too structurally complex.

To eliminate that possibility, the user split the research archive into multiple independent date-range volumes instead of one long document. Examples included separate volumes such as:

2026-08-01 through 2026-08-10
2026-09-01 through 2026-09-09
2026-09-11 through 2026-09-20

The schedules were also separated so that different jobs would not write to overlapping files. This was specifically done to reduce document size, reduce heading-navigation complexity, and reduce write conflicts.

The failures did not disappear.

3. Suspected cause: prompt / task instructions were too long

The user also suspected that the scheduled prompt itself might be too long or too complicated. They reduced the prompt and removed unrelated historical instructions. They narrowed each task so that it had one role and one output target, rather than combining repair, research, formatting, device design, and other responsibilities.

Again, the persistence problem remained.

4. Suspected cause: Google Docs formatting / document model

The next hypothesis was that Google Docs itself was a poor persistence format for this workload because it requires document-structure navigation, heading resolution, field masks, insertion locations, etc.

The user therefore moved toward plain-text / Markdown persistence. The goal was to eliminate Google Docs paragraph/heading semantics, structured-document insertion behavior, field-mask behavior, rich-text formatting, and ambiguous insertion positions.

The user explicitly preferred a simple read-latest-full-file -> modify -> write-full-file -> verify workflow.

5. Suspected cause: Google Drive connector reliability

Even after converting content to Markdown, the user still suspected that Google Drive itself might be contributing to the failures. So the user abandoned Google Drive as the persistence backend and migrated the workflow to GitHub.

This migration was not cosmetic. The user intentionally changed the architecture to a simpler storage model:

private GitHub repository
Markdown files
one branch
explicit file paths
Git-backed history
no Google Docs
no Google Drive
no GitHub Actions

The purpose was to remove the entire Google document/storage stack from the equation.

6. GitHub migration: stricter isolation and concurrency controls

The GitHub workflow was then made deliberately conservative. The schedules were redesigned so that each task had exactly one main writable file and all cross-role files were read-only.

The user also separated tasks to avoid concurrent writes to the same file and moved to hourly execution. Earlier schedules had already been split across independent volumes for the same reason.

The intended write path became:

read formal task configuration
read the latest target Markdown file
obtain latest blob/file state
perform research
re-read latest state immediately before writing
merge only the intended changes
write using the latest blob SHA
commit
re-read after commit and verify persistence

The prompt explicitly prohibits modification of unrelated files, other schedules, daily-report files, Google Drive, and GitHub Actions.

In other words, the workflow became more restricted than normal GitHub repository permissions.

7. The workflow was further simplified after migration

The user also cleaned up the migrated workspace so old Google-era schedule output would not accidentally be treated as active state. Old material was retained only as history / deduplication context where needed, while new schedules were instructed to use a new clean starting point.

For the new S2-S5 workflow, each role received a dedicated Markdown output file and could only read the other roles' files. The user repeatedly narrowed the system specifically to avoid exactly the kinds of ambiguity a safety layer might reasonably worry about.

8. Current failure: GitHub reads succeed, authorized write is blocked by safety check

After all of the above changes, the current failure mode is now:

GitHub connection works
repository reads work
configuration reads work
target-file reads work
research completes
latest state / blob SHA can be re-read
only one exact Markdown file is authorized for writing
the update is a normal non-destructive content update
nevertheless, the final GitHub file update is rejected by an internal safety check

The workflow retries after re-reading the latest blob state, and the write is blocked again. This has now happened on repeated runs.

At this point, the same user workflow has failed across:

long Google Docs
split Google Docs
shorter prompts
Markdown instead of Docs
Google Drive-backed Markdown
GitHub-backed Markdown
per-task isolated files
explicit latest-SHA writes
pre-write re-read
post-write verification logic

The user has therefore spent substantial effort eliminating storage format, file size, document structure, connector choice, prompt length, concurrent writes, and ambiguous write scope as possible causes.

The remaining blocker is now the platform's safety gate itself.

Reproduction

Connect a GitHub account to ChatGPT.
Give the workflow explicit permission/instructions to use one repository and one branch.
Restrict the workflow to a single writable file. In this reproduction, the prompt explicitly says that only one Markdown file may be modified and that all other files are read-only.
Have the workflow read its configuration files, read the target file, obtain the latest file/blob state, and prepare a normal content update.
Attempt the GitHub file update.
The read operations succeed, but the write is rejected by a safety check.
Re-read the latest file/blob state and retry the same authorized update.
The write is rejected again.

This happened on repeated runs of the same workflow.

Expected behavior

If the connected GitHub account has write permission and the user has explicitly authorized the exact repository, branch, and target file, a normal file update should be allowed.

If an additional safety confirmation is required, ChatGPT should surface a concrete confirmation step or a specific reason that the update is blocked, rather than silently making a user-authorized persistent workflow unable to save its work.

For recurring workflows, once the user has explicitly scoped authorization to one repository / branch / file, that authorization should be reusable for subsequent scheduled runs unless the requested mutation changes materially.

Actual behavior

The workflow can research, read the repository, read the latest target file, and prepare the update, but the final GitHub write is blocked by a safety check. As a result, the scheduled workflow repeatedly completes research work but cannot persist the result.

This is particularly disruptive for recurring workflows because a transient or false-positive safety gate turns every run into a failed write even though the user has already constrained the writable path.

The failure also causes wasted repeated work: a later run has to rediscover or reconstruct work that a previous run already completed but was unable to save.

Why this matters

The safety behavior is preventing the action the user explicitly authorized, rather than preventing an unexpected or broad mutation.

The user's workflow already applies a stricter boundary than normal repository permissions:

one named repository
one branch
one exact writable file per role
all other project files read-only
no Google Drive writes
no GitHub Actions
no schedule modification
re-read latest state before writing
latest blob SHA / concurrency-aware update
post-write verification
separate output files to avoid cross-task write conflicts

A safety system should distinguish this from ambiguous, destructive, cross-repository, or privilege-escalating writes.

The important point is that the user has repeatedly redesigned the workflow to satisfy increasingly conservative assumptions, yet each migration simply exposes another persistence failure. From the user's perspective, there is currently no reliable storage backend for a long-running ChatGPT scheduled workflow even when the task is narrowly scoped and explicitly authorized.

Suggested improvement

Do not block a narrowly scoped GitHub write solely because it is a write action when the user has explicitly authorized the exact repo/branch/file.
If the safety system has a specific concern, expose the reason in actionable terms.
Provide an explicit user confirmation/override path for a false positive.
For scheduled workflows, allow the authorization to persist for the exact pre-authorized file/path so the same false positive does not recur every hour.
Return a stable error code or diagnostic identifier so repeated failures can be reported and debugged.
Distinguish destructive / broad repository mutations from append-or-update operations on a single explicitly authorized file.
Do not treat persistence failure as successful task completion.
For scheduled workflows, preserve enough execution state that completed research is not lost merely because the final persistence call is blocked.
Consider first-class support for durable workflow state / files so users do not have to repeatedly migrate between Docs, Drive, Markdown, and GitHub just to obtain reliable persistence.

Privacy

No private repository contents or conversation transcript are included in this report. File names and date ranges above are representative workflow structure details only and do not contain research content.

Independent corroboration from another account/workflow. I have been troubleshooting what appears to be the same class of failure since September 24, 2026, and the pattern is broader than a single GitHub file or a blanket connector outage.

What I observed

1) Scheduled Google Drive / Docs / Sheets: reads continued to work, but some external writes did not complete.

Two affected Scheduled runs on September 24 could read the connected Google data and inspect the same control state they were expected to update, but the intended writeback did not land.

There was a known-good Scheduled write immediately beforehand:

2026-09-24 13:00:36 EDT — Scheduled write succeeded.
2026-09-24 13:18:31–13:21:10 EDT — first confirmed affected Scheduled run; expected Proof/EventBus persistence did not complete.
2026-09-24 13:30:18 EDT — second affected Scheduled run; three Google Docs write attempts did not complete.

The important point is that this was not a total loss of connector access: reads were still available, and other writes had succeeded shortly before.

2) Interactive ChatGPT vs Scheduled A/B difference.

During the same general period, equivalent connected-app writes from an ordinary interactive ChatGPT conversation could succeed while the Scheduled execution did not persist its write.

I also tested GitHub as an independent connector path. Interactive ChatGPT could produce a commit to the same connected repository, while the Scheduled test recorded a run but produced no target file/blob change and no new commit.

That made a blanket Google OAuth failure or a provider-wide outage unlikely.

3) On September 28 I finally got an explicit OpenAI-side rejection string.

A Google Sheets mutation against the migrated control environment attempted to write a bounded maintenance row:

Leases!A431:H431

The exact tool response was:

This tool call was blocked by OpenAI because we couldn't determine the safety status of the request.

I immediately re-read the target afterward. The target range was still empty and the intended configuration changes had not been applied.

This is the clearest evidence I have that at least one failure was being stopped inside the OpenAI action/safety path before the intended target changed.

4) The migrated environment can also perform successful writes.

Separately, a migrated cloud-executor transaction successfully wrote persistent state, exact-readback verified it, and recorded a durability receipt.

So the environment is not simply "unable to write". I have verified both:

successful connected writes with readback, and
blocked connected writes in the same broader environment.

That is why this looks intermittent / execution-path-dependent rather than a simple missing permission.

Missing diagnostics / UX problem

For the original Scheduled failures there was:

no actionable approval card,
no request ID,
no classification ID,
no provider HTTP error,
no clear "approval required" surface,
and no user-visible explanation of where the write stopped.

The write simply did not happen.

For a background Scheduled task, that is especially difficult to debug because the user only discovers the failure later by checking the target state.

Current hypothesis boundary

I am not claiming the internal root cause is definitely the same as this issue, but the observed pattern is highly similar:

Scheduled / unattended execution
→ connected app read succeeds
→ benign, user-authorized external mutation attempted
→ write is blocked or disappears before persistence
→ ordinary interactive execution may still succeed
→ little or no actionable diagnostic information is exposed.

The September 28 wording ("couldn't determine the safety status") also suggests an indeterminate/false-positive safety classification rather than a normal provider permission error, but only OpenAI backend telemetry can confirm that.

I am not asking for any safety bypass. I want a legitimate, narrowly scoped connected-app write either to execute consistently or to surface a concrete approval/rejection reason and a supported recovery path.

I have an open OpenAI Support case for this as well: Case #15750291. The support case contains the private automation/conversation/run identifiers and timestamps for backend correlation; I am intentionally not posting those private identifiers here.

This issue is the closest public report I have found to what I am seeing, so adding this as independent corroboration in case it helps connect the failures to the same underlying bug family.

I'm seeing a very similar problem in a normal ChatGPT scheduled workflow, but with Google Drive / Google Docs rather than GitHub.

My workflow reads two Google Docs, computes a daily result, and appends a short record. This used to work. Recently, the reads still succeed, but the write can be blocked before it reaches Google with:

This tool call was blocked by OpenAI's safety checks.

I initially suspected prompt length or document size, so I reduced the write substantially and even retried with only a tiny record (date / score / model). The short write was still blocked by the same OpenAI safety check, while Google reads continued to work normally. I did not receive a Google 403 / authorization / permission error.

Because this is a scheduled workflow, the failure is especially disruptive: the reasoning can complete, but the result is not persisted. I have now had to split the workflow into a 00:05 main run and a 00:20 watchdog/recovery run, and also split writes into smaller chunks, just to make persistence more resilient.

So this appears consistent with the issue described here: user-authorized, narrowly scoped persistence actions are being false-positively blocked by the platform safety layer, even when the storage backend and write scope are explicit.

It would be very helpful to have:

a stable diagnostic/error ID for these safety blocks;
a clear distinction between OpenAI safety-layer rejection and provider/API rejection;
an explicit confirmation/override path for benign false positives;
reliable reusable authorization for scheduled workflows that write to a pre-authorized document/file.

This is currently making previously working scheduled persistence unreliable.

Additional reproduction: GitHub writes fail intermittently in Scheduled Tasks but succeed in interactive ChatGPT

I have encountered a very similar issue with a ChatGPT Scheduled Task that maintains Markdown security notes in a user-owned, private GitHub repository.

The workflow reads the remote main branch, creates a daily Markdown file, updates README.md, and verifies the resulting commits.

Observed timeline (JST, UTC+9):

Date	Scheduled task result
Sep 28, 2026	Created the daily Markdown note (#53) and weekly recap successfully. The task reported that three attempts to update README were blocked by safety checks.
Sep 29, 2026	Created the daily Markdown note (#54) successfully, but again reported three failed README update attempts.
Sep 30, 2026	Reported three failed attempts to create the next daily note (#55). I subsequently paused the recurring task to avoid accumulating incomplete updates.
Oct 1, 2026	I requested the missing README changes through an ordinary interactive ChatGPT conversation. The update succeeded on the first attempt.

Additional verification from the successful interactive run:

The GitHub connector was authenticated.
The repository metadata confirmed admin: true and push: true.
Its default branch was main.
Reading README.md worked normally.
Updating the same README through the connected GitHub tool succeeded.
A subsequent remote read confirmed that the missing OpenAI rejected the request (request ID: req_xxx). Please verify your settings and try again. #53 and Add OpenRouter model support #54 entries and the weekly recap link were present.
The resulting commit was verified: 923e4a1b6a256bfe87b62f4abf9519628269a478.

This suggests the connector does not have a blanket write-permission problem. The failures appear intermittent and potentially dependent on the execution context, operation, or payload.

Diagnostic limitation: The safety-check failures above were reported by the Scheduled Task. I do not have direct access to the underlying safety-classifier telemetry or a request ID, so I cannot independently establish the precise rejection reason or prove that every failed attempt had the same root cause.

It would be valuable to investigate:

Why an explicitly authorized GitHub write can fail in a scheduled execution but succeed in an interactive conversation.
Whether the safety evaluation differs between the two execution contexts.
Why creating a Markdown file may succeed while updating README fails during the same workflow.
Whether blocked operations could expose a stable diagnostic/request ID and a reason category.
Whether Scheduled Tasks can provide a supported recovery mechanism for authorized external writes without weakening safety checks.

I can provide the private repository identifier, Scheduled Task details, conversation references, and additional timestamps privately to OpenAI Support if needed.

Independent corroboration from another ChatGPT account/workflow. This looks like the same bug family, with one additional Work-vs-Scheduled-vs-interactive distinction that may help narrow it down.

What I reproduced

The connected GitHub plugin is configured in ChatGPT Settings with “Allow all tools”.
Ordinary interactive ChatGPT can successfully create/update files in the connected repository.
A one-shot Scheduled task was given a unique Markdown path and exact file contents, with instructions to make no other changes.
The Scheduled task did run (2026-10-02 21:09 UTC), but afterward the target file did not exist on the remote (confirmed by a direct read returning 404).
No approval prompt surfaced to the user during that Scheduled run, and the Scheduled UI did not expose a detailed failure/approval state that the user could inspect.
The same class of GitHub file creation succeeds when retried from an ordinary interactive ChatGPT conversation.

Work behaves differently again

In a ChatGPT Work session, GitHub mutation did not fail silently. Instead, Work surfaced an approval dialog:

“Allow ChatGPT to use GitHub?”
“ChatGPT will call GitHub’s Create Tree tool.”

The dialog offered Always allow / Allow once / Deny even though the GitHub plugin was already set to Allow all tools in Settings.

So on the same account/integration we are seeing three different behaviors:

Interactive chat: write succeeds.
Work: write can surface an approval prompt despite “Allow all tools”.
Scheduled: write can fail to persist with no user-visible approval prompt and no useful run diagnostic.

Additional permission-resolution inconsistency

While troubleshooting, the ChatGPT plugin directory reported the exact GitHub connector as installed and enabled. Querying permissions by the human-readable app name (“GitHub”) returned the app-specific Allow all tools state, but querying by that connector’s exact internal ID reported that the plugin was not installed and fell back to the default permission state.

I cannot prove that identity mismatch is the root cause, but it is consistent with execution-context-dependent permission/safety resolution.

OpenAI Support case #16305319 has the screenshots and private timing/context details for backend correlation.

I’m not asking for a bypass; the desired behavior is the same as the reports above: a narrowly scoped, user-authorized write should either execute consistently or surface a concrete approval/rejection reason plus a recoverable path.

I can reproduce what appears to be the same scheduled-task/GitHub-write failure, with an A/B comparison against an interactive ChatGPT conversation.

On 2026-10-04, a scheduled ChatGPT editorial task using the connected GitHub integration successfully performed reads and created its target branch, but the subsequent benign article create_file operation was blocked with:

This tool call was blocked by OpenAI's safety checks.

The file never reached GitHub.

I then tested from a normal interactive ChatGPT conversation using the same connected GitHub account, repository and branch:

a diagnostic create_file succeeded;
reading it back succeeded;
deleting it succeeded;
most importantly, writing the actual full article payload that had been blocked during the scheduled run succeeded;
creating the associated JSON job file succeeded;
creating a Draft PR and applying its label succeeded;
post-write verification succeeded.

I reproduced the scheduled-task failure again on 2026-10-05 with an especially clean sequence:

the scheduled task freshly read its workflow contract from the repository's main branch;
required GitHub reads succeeded;
idempotency checks succeeded;
the current main HEAD was read;
creation of a new editorial branch from that exact HEAD succeeded;
the very first article file write was blocked by OpenAI's safety checks;
following the workflow's safety rules, no retry was attempted;
subsequent verification showed the new branch was still identical to main, with zero changed files and no article file present.

Observed behavior:

Scheduled ChatGPT task + GitHub read/branch creation -> succeeds

Scheduled ChatGPT task + GitHub create_file -> blocked by OpenAI safety checks

Interactive ChatGPT conversation + same GitHub connector/repository + equivalent/actual payload -> succeeds

This makes GitHub repository permissions and the article payload itself unlikely causes. It looks strongly context-dependent on scheduled execution and/or the pre-dispatch safety layer applied to mutating connector actions.

I also reported the earlier reproduction in #43312, but this issue appears much closer to the scheduled-workflow behavior I am seeing.

Happy to provide additional reproduction details if useful.

Additional reproduction from 2026-10-05 that may help narrow the safety-check behavior.

I ran an A/B test against the same user-authorized GitHub workflow after a scheduled run had left an incomplete editorial branch.

Initial state

The scheduled run had already created the intended branch.
The branch was still identical to main: 0 commits / 0 changed files.
No PR existed.
The workflow contract explicitly required recovering that same branch rather than creating a replacement.

Scheduled run

The scheduled/automation execution attempted to create the normal Markdown article and the mutation was rejected by the safety layer.

Interactive run, same day and same branch

I then manually resumed the same workflow from an interactive ChatGPT conversation:

Re-read the current workflow contract and mandatory repository files.
Re-verified that the incomplete branch was identical to main.
Performed the article create_file mutation on that exact branch.
The Markdown article write succeeded.
Immediately afterward, attempted the second expected mutation: creating the small JSON image-job file on the same branch.
That JSON create_file was rejected by the OpenAI safety check.

The observed matrix is therefore:

Context	Mutation	Result
Scheduled workflow	create article Markdown	❌ blocked by safety check
Interactive conversation	create same article Markdown	✅ succeeded
Interactive conversation	create related JSON job	❌ blocked by safety check

After the JSON write was blocked, I did not blindly retry. I re-read GitHub state instead. Verification showed exactly one new commit/file (the successfully created article), the JSON job was absent, VERSION was unchanged, and no PR had been created.

This seems useful because it suggests the issue is not simply “GitHub writes are disabled in scheduled tasks.” Execution context clearly affects the result, because the article mutation that failed scheduled succeeded interactively. However, an interactive mutation can also hit the same safety gate, so the false positive appears to depend on some combination of execution context, individual mutation/payload, or safety-state evaluation.

The GitHub permissions and repository state were sufficient for the successful write, which also makes a normal GitHub authorization/branch-protection failure unlikely.

I am intentionally omitting the private repository name and article contents, but can provide more structural details if useful.

Additional reproduction from a ChatGPT scheduled task using the GitHub connector (private repo, connector configured to allow all actions, account has admin/push on the repo).

Workflow: an hourly scheduled task fetches a Markdown runbook from the repo, reviews open pull requests, then posts (1) a formal PR review (add_review_to_pr, event=COMMENT, commit_id set), and (2) a short log comment on an issue (add_comment_to_issue). Occasionally it also creates one small file update (update_file). Review bodies are plain text: a hidden HTML marker comment, a one-line verdict and a few findings.

Timeline (UTC):

2026-10-07 06:59: pass completed normally. Multiple add_review_to_pr and add_comment_to_issue calls succeeded, zero failures.
2026-10-07 08:49: update_file returned This tool call was blocked by OpenAI's safety checks. Please double check what you are sending. An identical retry succeeded.
2026-10-07 ~09:00 to 2026-10-08 05:00: almost every hourly pass aborted at the first write with the same error. Reads all succeeded.
2026-10-08 06:52 and 06:56: two passes succeeded normally, including reviews and comments.
2026-10-08 10:51: pass refused on all 18 write attempts (3 formal reviews, 1 update_file, issue/comment writes, each retried up to 3 times with identical arguments), every one with the same message. No write reached GitHub.

What this rules out on our side:

Same token, repo, tool names and payload shapes succeed in some passes and fail in others, so it is not GitHub permissions, branch protection or a malformed request.
GitHub never returns a response (no HTTP status), consistent with the call being stopped before dispatch.
Reads are unaffected throughout.
We reduced writes per pass (removed a redundant mirror comment and a start-marker comment) and added re-read-then-retry. That made no difference to the 10:51 pass.

Concerns:

The block gives no category or reason, so there is no way to tell what is being objected to.
Retrying a refused identical call sometimes succeeds and sometimes doesn't, so automation can't distinguish a transient refusal from a persistent one.
As others note in Repeated false-positive cybersecurity safety checks can escalate into near-every-turn checks across ChatGPT and Codex #43312, repeated refusals may escalate account-level checks. If so, retries (which users add precisely because of point 2) could make it worse.

Happy to provide timestamps or conversation IDs privately if that helps.

Independent confirmation from a fleet of ~15 recurring ChatGPT Work / Scheduled Tasks on the web (September–October 2026). The owner reports that manually initiated workflows generally work with the same GitHub/Google Drive connections, but unattended hourly workers intermittently fail to persist authorized changes.

App-specific GitHub and Google Drive permissions are explicitly Allow all actions (not merely the global default).
The scheduled GitHub failures include create_blob and create_file refused by a host safety check rather than an observed GitHub HTTP response. Read operations and other authorized writes can succeed.
Public operator-side evidence: Oct 8 create_blob block followed by an eventual successful write path; Oct 8 scheduled create_file refusal and working owner-session canary.
In an owner-initiated interactive session on Oct 10, GitHub issue creation and readback worked, confirming a functioning interactive mutation path. This specific comparison was not byte-identical to the scheduled operation. Other comments above provide stronger exact-content A/B demonstrations.
Google Drive/Docs failures were also observed, but some are different classes (file-reference handoff failure; successful positional insert corrupting adjacent text) rather than proved instances of this exact safety gate.

The consequence is operationally serious: scheduled agents can reason, read, and seemingly finish a run without leaving the expected remote artifact. The agent cannot be required to write a raw error log via the same blocked connector; host-owned per-run execution traces and an explicit pre-provider refusal/approval reason are needed.

I opened a broader cross-connector report, not another GitHub-only reproduction: #52872. It includes source evidence, limitations, and a proposed controlled manual-vs-scheduled test. If the Work/Scheduled backend belongs to another OpenAI team, please route both there.

Additional reproduction: identical retries recover file writes, but Draft PR creation fails 11 consecutive times

I would like to contribute another observation from an authorized ChatGPT Scheduled Task using the GitHub connector.

Environment

ChatGPT scheduled workflow, October 10, 2026.
User-owned GitHub repository with authorized read/write access.
The workflow reads a Markdown contract, creates a working branch, writes one Markdown file and one JSON metadata file, then opens a Draft PR.
All operations use the same authorized GitHub connector.
No alternative API, connector, or write method was used.

Observed behavior

Repository reads and branch operations succeeded.
A Markdown create_file operation encountered the following error:

This tool call was blocked by OpenAI's safety checks. Please double check what you are sending.
The workflow checked remote persistence and retried with identical arguments. During the traceable recovery sequence, a blocked invocation was followed by a successful identical invocation after approximately 20 seconds. The resulting file and commit were verified by reading GitHub.
Creation of the associated JSON file initially encountered the same safety-check error. Two attempts were rejected; the third succeeded after real backoff intervals of approximately 5 and 10 seconds. The resulting file and commit were independently verified.
The subsequent create_pull_request operation, intended to create a Draft PR for the same branch, was rejected 11 consecutive times with the same safety-check message.
The PR operation was retried with unchanged arguments and actual progressive delays of 5, 10, 15, 20, 25, 30, 40, 45, 50 and 60 seconds.
After each failed attempt, the workflow checked GitHub for an existing PR associated with the branch. No PR was found.

Final verified state

The working branch exists.
Both intended files exist and their commits were verified.
No Draft PR was created.
The workflow stopped after exhausting its configured retry limit, preserving the valid remote changes.

Why this reproduction may be useful

This shows two different outcomes within the same scheduled execution:

create_file: initially blocked, then succeeds with identical arguments.
create_pull_request: consistently blocked across 11 attempts despite unchanged arguments and verified absence of the intended PR.

The successful identical file-write retries suggest that at least some safety-check refusals are transient rather than permanent judgments about the request.

However, the PR failure demonstrates that retrying is not a reliable recovery mechanism in every case.

This does not establish whether the difference is caused by operation type, execution context, request payload, safety-state evaluation, or another internal factor.

The connector response exposed no provider HTTP error, stable diagnostic identifier, or actionable reason category.

Suggested investigation

It would be particularly useful to correlate safety-check decisions across different GitHub mutation tools within the same scheduled run, and determine why an authorized file write can eventually succeed while an authorized Draft PR creation remains consistently blocked.

The desired outcome is reliable execution of authorized mutations, or a clear, actionable rejection reason and supported recovery mechanism—not a bypass of safety controls.

@ZioTano

Follow-up to my October 10 corroboration — October 18

Additional cross-provider reports have since appeared in #52872: scheduled Resend sends reported as safety-blocked, and two small Google Sheets writes reported denied despite full app access with unchanged-cell readback. Evidence strengths and limitations are summarized here: #52872 (comment) .

In my interactive ChatGPT Web session today, a GitHub comment write and a revision-guarded Google Docs append both succeeded and were separately read back. This is a fresh working-path control, not a same-payload scheduled/manual A/B or proof of a fix; no new scheduled reproduction was run today.

The action-specific distinction in @ZioTano's last comment is important: a successful file write does not establish that a subsequent PR creation will work. Please expose approval/safety and provider-dispatch diagnostics per action, with terminal operation recovery independent of the chat UI. No safety bypass is requested.

Additional reproduction: interactive ChatGPT Web → local Desktop Commander blocked on benign diagnostic commands (2026-10-20)

I encountered a closely related failure in an interactive ChatGPT Web session using a connected, user-authorized Desktop Commander tool on my own Windows 11 PC. The purpose was to check an existing SSH connection to my own Raspberry Pi before installing a text-to-speech service.

What was verified separately: A different, narrowly scoped infrastructure connector successfully authenticated the Raspberry Pi over the established SSH route and read non-sensitive host facts. This is therefore not evidence that the Pi or its SSH service was unavailable.

Blocked tool calls: Both requests to the local Desktop Commander start_process tool were refused before any observed command output:

A read-only PowerShell diagnostic to locate plink.exe and query non-sensitive Pi host information over the existing SSH alias.
A still simpler local diagnostic: where.exe plink, with no SSH connection, system mutation, repository write, or file modification.

Both returned the same host-side message:

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

No actionable reason, approval prompt, policy category, or request/correlation ID was supplied. The second request is particularly useful diagnostically because it was merely a local executable-location lookup, not a write or remote operation.

Scope / uncertainty: This may not share the underlying cause of the GitHub/Google scheduled write failures discussed above. It does, however, extend the observed symptom to a user-initiated interactive local-command tool invocation. We cannot establish whether the call was rejected in a shared safety layer or by an action-specific policy without platform telemetry.

It would help to expose a stable diagnostic ID, the rejected action category, and an actionable user-approval/recovery path for narrowly scoped legitimate device administration. No bypass is requested, and no private IP address, credentials, or repository contents are included here.

[ChatGPT Web][GitHub] User-authorized file update repeatedly blocked by safety check #48940

Description

Summary

Visual summary of the troubleshooting journey

Product / surface

Full history / why this is not a one-off

1. Original workflow: long-running scheduled research written into Google Docs

2. Suspected cause: Google Docs became too long

3. Suspected cause: prompt / task instructions were too long

4. Suspected cause: Google Docs formatting / document model

5. Suspected cause: Google Drive connector reliability

6. GitHub migration: stricter isolation and concurrency controls

7. The workflow was further simplified after migration

8. Current failure: GitHub reads succeed, authorized write is blocked by safety check

Reproduction

Expected behavior

Actual behavior

Why this matters

Suggested improvement

Privacy

Activity

h1147255676-ship-it commented on Sep 29, 2026

What I observed

Missing diagnostics / UX problem

Current hypothesis boundary

jeonghakhui-art commented on Sep 30, 2026

Diaboro87 commented on Oct 2, 2026

apolito53 commented on Oct 4, 2026

What I reproduced

Work behaves differently again

Additional permission-resolution inconsistency

ZioTano commented on Oct 5, 2026

ZioTano commented on Oct 5, 2026

Initial state

Scheduled run

Interactive run, same day and same branch

alexpitcher commented on Oct 8, 2026

drevendev commented on Oct 10, 2026

ZioTano commented on Oct 10, 2026

Additional reproduction: identical retries recover file writes, but Draft PR creation fails 11 consecutive times

drevendev commented on Oct 18, 2026

Follow-up to my October 10 corroboration — October 18

Melbar666 commented on Oct 20, 2026

Additional reproduction: interactive ChatGPT Web → local Desktop Commander blocked on benign diagnostic commands (2026-10-20)

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions