[Dots][GitHub tools] Later user authorization is not reliably recognized across development and read-only reporting tasks

During October 3–4, 2026 (UTC), development coordinated through dots encountered repeated pre-execution approval blocks. The user had authorized development and publication, while separate scheduled progress reports were read-only. Later denials continued to cite read-only scope or missing authorization.

Environment:

macOS, dots-managed cloud work, GitHub integration, and delegated execution on the connected Mac.
GitHub CLI: 2.101.0. Exact Codex/client/backend builds are unknown.

Incident timeline (reconstructed; not a deterministic minimal reproduction):

October 3: The user initially received rejection reports without an actionable explanation or recovery path. We cannot establish whether the underlying reason was absent or inadequately surfaced. Later diagnostic evidence contained a public-source-upload refusal stating that approval did not unambiguously cover the exact payload and destination, despite an explicit public-exposure explanation and the user's subsequent instruction to proceed. Repository ownership and push access were independently verified. Exact original invocation timestamps and request IDs were unavailable.
The user subsequently published the prepared source from another independently operated Mac session. The resulting source tree matched the prepared files. A later PR creation through dots and CI reads succeeded. This rules out a blanket inability to access or write to GitHub, but is not a controlled same-session comparison.
In a separate private-repository development workflow, tree creation and a PR-review request were denied with explanations citing the read-only reporting restriction and no later authorization. The user had directly requested development to resume after the reporting task.
October 4, around 01:48 UTC: A previously rejected second tree-upload batch succeeded after renewed user instructions. Batches 3–10 then succeeded. Batch 11 was denied on read-only-scope grounds. Its retry was denied on additional grounds of a large private source upload to an unverified destination. Prior read-only checks had verified repository identity, ownership and private visibility.
Around 01:53 UTC: The assistant asked specifically about uploading the reviewed source/tests to that private repository and creating a draft PR with CI, separately from the read-only report. The user approved. Batch 11 and commit creation then succeeded, with remote source-tree verification.
Around 01:55 UTC: The subsequent branch-creation call returned “user cancelled MCP tool call”. At 02:15 UTC, the user explicitly stated they had not cancelled anything. The actual cancellation source is unknown. This is distinct from another long-running call the coordinating assistant intentionally interrupted.
At the user's request, the workflow moved to gh CLI on the connected Mac. Read-only authentication/repository checks succeeded. Branch creation was still rejected before command execution, citing the original read-only scope and treating forwarded later approval as insufficiently attributable. One retry with the original question and user response was also denied. No branch, draft PR or CI run resulted for this private-repository candidate.

Expected behavior:
Evaluate each action using attributable current user authorization and the scope of the applicable task, while preserving safety restrictions. When approval is insufficient, identify precisely what is missing and provide a supported recovery path. Expose useful diagnostic references and distinguish user cancellation from other interruptions.

Limits:
Different batches contain different payloads, so their differing outcomes do not prove nondeterminism for identical inputs. We have not established a single root cause, a GitHub permission defect, or a payload-size limit. The CLI write failures described above occurred before the command ran; they were not errors returned by gh or GitHub.

Related reports:
#50673
#44085
#45732
Please consolidate if appropriate.

Private repository names, source code, personal information, credentials, internal identifiers and raw conversations are omitted.

This report was prepared and submitted through the user's dot, with the user's review and approval. It distinguishes observed tool results, user-reported facts, and a reconstructed incident timeline.

Adding an iPhone-to-Mac approval-path observation from October 5–6, 2026 (UTC):

From my main dot conversation on iPhone, I coordinated work on my connected Mac. Source changes, builds, tests, export and upload succeeded.
A narrow, security-sensitive local configuration change required approval. I was shown the exact change and its effect and replied “Yes” in the main chat.
My dot relayed the exact question and answer. The execution task reported that the forwarded approval was untrusted, and the change remained blocked.
That task wasn’t visible in my iPhone Codex task list, although ordinary remote sessions and my connected computer were visible. This overlaps with the visibility problem in [Dots][macOS → Mobile Remote] Dot-created Mac tasks are missing from the task list even after pinning #49848.
No actionable approval control or request ID was returned to the main chat. No bypass was performed.

Please provide a secure way to attribute main-chat approval to the exact task action, or return a real action-time approval request to the main chat. Approval should be possible without repeatedly switching into tasks I can’t access. This observation doesn’t establish a shared root cause.

@unwashedlugosi

The new iPhone → Mac observation from @unwashedlugosi adds a fourth layer that is worth keeping separate from the three already discussed here:

the user made an authorization decision
!=
that decision was admitted/delivered to the delegated task
!=
the delegated executor/reviewer can consume it for the exact action
!=
the user has a reachable action-time approval channel when a fresh grant is required

That last distinction matters in this case because the delegated task reports the forwarded approval as untrusted, while the user also reports that the task itself is not reachable from the iPhone task list and no actionable approval request is returned to the parent conversation. #49848 independently documents the visibility problem for Dot-created durable tasks, so “ask the user again in the child task” is not necessarily a usable recovery path.

A bounded regression could pin this without weakening review:

user authorizes exact action A in the parent Dot conversation;
Dot delegates A to task T;
if T cannot consume a transferable grant, the reviewer emits an approval_request_id bound to T + exact action/destination digest;
that request is surfaced through a user-reachable first-party route (parent conversation and/or Remote approval UI), even if T itself is not list-visible;
approving that exact request produces a verifiable current grant and A may proceed once;
changing action/destination materially, expiry, revocation, or excess retry requires a new request;
an internal denial/interruption remains distinct from an explicit user cancellation event.

The useful product property is therefore not only authorization provenance, but authorization reachability: when current authority must be re-established, the system needs a supported path by which the human can actually service the exact pending decision.

This new report does not establish a shared root cause between #50769 and #49848. It does make the cross-surface acceptance condition testable: a hidden/unreachable delegated task must not make a legitimate exact-action approval impossible to complete.

Adding a separate dot incident from October 7, 2026 (UTC): authorized actions across Gmail, Google Drive, Google Sheets, Calendar, and task messaging intermittently reported "user cancelled MCP tool call". The user explicitly says they did not cancel. They also report that this happened before connecting the current Mac Studio.

This concerns dot and connected-app/task workflows. Exact client and hosted backend versions are unknown.

Observed sequence, reconstructed rather than a deterministic reproduction:

Drive folder creation failed, then succeeded on retry.
A Sheets update failed twice; read-back showed the previous 20 rows unchanged.
Several Gmail sends succeeded; later calls failed, with mixed outcomes on explicitly authorized retries.
An email reply failed twice; Sent checks found no matching message.
Calendar creation failed initially, then creation and update succeeded.
Continuing an existing task failed; read-back found no admitted continuation. A later authorized retry started successfully.
Separately, an approved custom-rule form did not save, reporting customRuleNotSaved/unavailable. A widget-caption failure occurred despite the card being visible. A common cause with the cancellations is not established.

For the task-continuation example, the call began between 13:05:05 and 13:05:21 UTC, a user message arrived at 13:05:33, and cancellation was observed by 13:05:56. A later retry between 13:19:25 and 13:20:11 was admitted. These are transcript bounds, not exact backend latency. The ordering does not establish that the incoming message caused cancellation or that a particular timeout was reached.

The cancellation wording is also ambiguous in the current public source. At commit 95ec468:

We have not established which source revision or branch handled these dot calls. This source inspection does not identify their root cause.

Related observations include today's Gmail/task-creation report and the mail-backend report where a matching backend call succeeded while the caller reported cancellation. Those reports reinforce the need to verify external state before retrying; a shared cause is not asserted, including with the original CLI configuration issue in #29857.

Expected: distinguish explicit user cancellation from internal approval failure, unavailable response, timeout, and transport/result-delivery failure; expose whether the destination executed the action and provide a correlation reference.

Please correlate approval creation/resolution, cancellation actor and reason, task/turn lifecycle, connector dispatch, and result delivery. Failed invocation IDs were unavailable. No additional mutation probes or permission changes were performed for this diagnosis.

Prepared and posted through the user's dot with the user's approval. Private content, mailbox/account identifiers, task IDs, invoice details, secrets, and raw transcripts are omitted.

@odedd

The new cross-connector report from @odedd adds one failure boundary that is not fully covered by the authorization-handoff model above:

user decision
!=
authorization admission / delivery
!=
authority consumption for the exact action
!=
connector dispatch
!=
external effect committed
!=
result delivered back to the caller
!=
the caller's user-visible failure classification

That matters especially for effectful operations. A caller seeing user cancelled MCP tool call, timeout, or another interrupted result does not by itself establish that the destination performed no effect. The report's mixed read-backs make that distinction operational, not only diagnostic.

I would extend the decision/authorization trace with an effect/result leg, for example:

operation_id / action_digest
authorization_receipt_id
review_trace_id
dispatch_id
dispatch_state: not_dispatched | dispatched | unknown
external_effect_state: absent | committed | unknown
result_delivery_state: delivered | lost | interrupted | unknown
user_cancel_event_id: <id> | none
failure_class

Then a focused regression can separate at least these cases:

review fails before dispatch -> not_dispatched / absent;
dispatch occurs and the provider commits, but result delivery fails -> committed / result_lost, not “user cancelled”;
dispatch outcome is unknowable -> UNKNOWN; reconcile/read back before retrying an effectful action;
explicit user cancellation before dispatch -> bind the classification to an actual user-origin cancellation event;
explicit user cancellation after a provider may already have committed -> cancellation may stop further work, but it must not rewrite the historical effect state to “did not happen”;
a safe retry after ABSENT still revalidates current authority rather than treating the old authorization as permanent.

The negative invariant is:

missing/failed result delivery
!=
proof of no external side effect

and, separately:

internal abort / interrupted approval / transport failure
!=
proof of user intent to cancel

This keeps the existing safety checks intact while making retries safer: an ambiguous caller result should first answer “did the effect happen?” before it answers “may I try again?”

Adding an October 8, 2026 dot/Slack incident, following my earlier connected-app cancellation report.

I authorized a Slack message.
The send from the main dot conversation returned only user cancelled MCP tool call.
I had not cancelled it and explicitly told the dot that.
A read of the destination thread found no corresponding message.
A later authorized retry for the same purpose succeeded.

The read-back confirms absence from that destination before retrying, not whether Slack received the failed request or which component produced the error. The failed and successful requests were not established to be byte-identical.

This is separate from explicit approval-review rejections encountered in delegated tasks. A shared cause has not been established, including with the original CLI configuration issue in #29857.

Please distinguish actual user cancellation from unavailable/interrupted approval, explicit review denial, and transport/result-delivery failure. A correlation reference and an indication of whether the external action executed would make recovery safer.

Current client/backend versions and the cancellation source are unverified. Private message content, account/channel IDs and raw conversations are omitted.

Adding a separate October 8 example about interpretation of user intent, distinct from my earlier cancellation report here.

I was discussing a local folder-based message connection. I said I did not want it to go through Slack. In context, I meant the operational message transport: I wanted messages to go through a folder on my PC instead. I was still allowing my dot to coordinate the setup with another assistant on Slack.

The dot then tried to send that assistant a status question: whether the local mailbox server had already been prepared or only the session wake-up command had been tested. The message explicitly requested status only, no installation or configuration changes, no credentials, and no restoration of the Slack transport.

The approval review rejected this because it interpreted my no-Slack requirement as also prohibiting setup clarification in that Slack destination. That was broader than what I intended. I had to explicitly authorize Slack communication again. The same status-message tool call then succeeded.

This is the behavior I want to report: a contextual restriction is extracted from the conversation and applied as a blanket prohibition to a different activity. The workflow stops while I repeatedly restate the intended scope. It is not simply a tool returning 'user cancelled'.

Expected: distinguish the subject and scope of a restriction (runtime transport versus setup coordination here), and consider current explicit authorization for the concrete recipient and purpose. If the scope is genuinely ambiguous, surface that specific ambiguity rather than treating the broadest interpretation as established user intent.

This is one observed incident, not a deterministic reproduction or a confirmed internal root cause. Private names, channel/account identifiers, credentials and raw conversations are omitted.

Adding another observation from October 8, 2026. After an earlier stop instruction, I gave fresh approval for a specific action in my main dot conversation. My dot relayed that approval, but the delegated task continued to report the earlier stop as a blocker.

The useful distinction here is between approval reaching the task and the current authorization being available and accepted when the action is reviewed. I cannot verify what context reached that review.

Please provide a reliable way for a later, scoped user decision to supersede an earlier stop for that action. If another approval is required, please surface an actionable request in the main chat and identify what is missing.

This is an observed incident, not a deterministic reproduction or a confirmed root cause.

Follow-up to my October 4 backup report, adding a new-repository diagnostic from October 9, 2026. Times below are approximate UTC.

New repository comparison

Around 04:13, an authenticated owner browser session successfully created a new private GitHub repository with a README.
Native GitHub connector readback verified its private visibility and initialized main branch. Existing-repository reads also succeeded.
Around 04:14, native create_branch against this new repository returned exactly user cancelled MCP tool call, with isError: true.
Read-only reconciliation found only main and zero PRs. No diagnostic branch was observed; subsequent file-write and PR tests were not completed.

This adds evidence that the observed symptom is not confined to the old repository. It does not establish GitHub-wide failure, connector write permissions, whether the failed request reached GitHub, or the cancellation source. Earlier incidents include my explicit denial of intentional cancellation; we did not capture a separate contemporaneous statement about the cancel control for this individual invocation.

Successful controls and separate execution symptom

GitLab code-MR merging and draft-MR creation/readback succeeded that day. This is not a report that all writes fail, or that the identical GitLab connector error was reproduced.

Separately, polling a read-only production backup-export execution returned:
Unified exec process failed: automatic approval review was cancelled

This occurred in two attempts and again in an explicitly authorized, sandbox-reviewed attempt around 03:49. A common cause with the GitHub MCP result is unverified. The data backup remained incomplete, while the separate code merge completed. A legacy exporter restart/truncation defect was identified separately in our script; we are not attributing that defect or data loss to the platform.

Diagnostic request

Please help identify:

Which observable event produced the user-cancellation classification.
Whether approval was created and shown, and whether the connector dispatched the request.
Whether a request/correlation reference can be obtained through private support using the UTC window.
How callers should distinguish explicit cancellation, interrupted review, and result-delivery failure, and safely reconcile external effects before retrying.

The user-facing operating history includes Windows Web and Android, with cloud Linux execution. Exact client/backend builds and a deterministic reproducer are unavailable. No remote HTTP rejection or cancellation-origin metadata was returned for the disputed calls. This report does not establish the deployed source revision or a shared cause with other reports.

Prepared through my dot and posted with my approval. Private repository/account/project identifiers, credentials, source/data content and raw conversations are omitted.

Adding a separate observed incident from dot's web interface on Windows. An explicitly approved GitHub issue-comment action remained blocked, then the same unchanged call succeeded after I reported switching a Codex chat back to Full Access.

Observed sequence (UTC):

October 8, 2026, 19:09:05: The GitHub connector action was rejected with “This action was rejected due to unacceptable risk.” The explanation treated the comment as a durable external decision beyond the available approval.
October 8, 19:09:41: The assistant specifically asked me to authorize the decision communicated by that comment.
October 9, 08:48:52: I replied “Да, конечно.” (“Yes, of course.”).
October 9, 08:49:54: The unchanged action was rejected again.
October 9, 08:58:20: I reported switching a Codex chat back to Full Access and explicitly requested another retry.
October 9, 08:59:13: The same unchanged comment action succeeded. Reading it back confirmed publication.

The rejection did not give us an actionable way to resolve the approval mismatch. No GitHub HTTP 403 was reported. I could not find an access-mode selector in the dot web interface.

This is a reconstructed incident, not a deterministic minimal reproducer. The Full Access change is user-reported; the assistant did not change the setting. The app/client and hosted-backend versions, the other chat's host association, and any permission linkage between that chat and dot are unknown. The timing does not establish that the setting change caused the successful retry, or that this incident shares the issue's root cause.

Please investigate how the current, action-specific human approval was evaluated. A useful failure response would identify the blocking layer, what authorization is missing, whether the denial can be reviewed, and the supported next step. Showing dot's effective permission mode and where it comes from would make this easier to diagnose.

Private repository and issue identifiers, comment content, local paths, hashes, credentials, session IDs, and raw transcripts are omitted.

Adding a read-only connected-app observation to the cross-connector reports above.

On October 10, 2026, around 00:36 UTC, I had explicitly authorized a bounded read-only check through an existing OAuth spreadsheet connection. Listing sheets succeeded. Reading a range from the same spreadsheet then returned only "user cancelled MCP tool call", with isError=true. No HTTP status, provider error code, request ID, or cancellation source was exposed.

A separate ChatGPT Space index-page update returned the same message, while another page update succeeded. These observations show partial success across services; they do not establish a common cause or whether the failed requests reached the providers. This is a dot connected-app observation, not a claim to reproduce a particular CLI configuration issue.

Could the error distinguish actual user cancellation from an approval interruption, explicit denial, timeout, or transport/result-delivery failure, and include an actionable correlation reference?

Client surface: ChatGPT web on Windows. Exact client/backend versions are unverified. Private content and connection/document identifiers are omitted.

Reviewed the duplicate suggestions on #52916. The cancellation-attribution symptom is already covered here, particularly in #50769 (comment). I am consolidating my additional Windows-desktop occurrence here rather than keeping another issue open.

On October 10, 2026, with user-reported desktop version 26.1007.21434:

I explicitly requested a no-op task in an existing saved cloud environment. The task prompt prohibited tool use, commands, browser actions, file inspection and changes.
The dot's cloud_threads.create call started around 15:49:36 UTC and returned user cancelled MCP tool call by 15:49:53 UTC, without a task/turn ID.
I saw no approval/cancellation prompt and did not cancel anything.
Latest child/account task listings did not show a newly created task from that attempt.
I explicitly approved a retry at 15:50:44 UTC. The same creation arguments succeeded by 15:51:04 UTC, and task readback confirmed the no-op acknowledgment.
A status question arrived while the first call was pending. It was not a Stop/Cancel instruction. Its causal significance is unknown; retry timing and surrounding authorization context also changed.

The retained record also includes two task-message delivery failures on October 5, a GitHub merge failure on October 6, cancellation-labelled GitHub updates on October 8, and comment/task-message failures earlier October 10. Those older records have differing evidence detail, documented in #52916. They are not fresh reproductions.

The distinctive new example is a small cloud-task creation request, without a large inline GitHub payload or a target-local-session approval prerequisite. This does not establish a different underlying bug. The misleading wording, absent user prompt, uncertain admission state and need to verify before retrying match the symptom already discussed here.

I am using the Windows desktop client, not a web client. Hosted backend build and cause remain unknown. No private environment, account, task, repository or domain identifiers are included.

Adding a separate dot/Slack occurrence from October 12, 2026, to the cross-connector reports here.

This is an observed incident record reconstructed from execution reports and destination readback, not a deterministic minimal reproduction. All times below are UTC tool-return times unless otherwise noted. Exact client/backend builds were not captured.

Observed sequence:

14:05:47: A message-send attempt failed while initializing automatic approval review. Separate verbatim excerpts from the result are: “Automatic approval review failed: Fatal error: Failed to initialize session:”; “500 Internal Server Error”; and “The action was not executed because automatic approval review could not be completed. This is a review failure, not a determination that the action is unsafe.” Internal service details between these excerpts are omitted. The invocation start time is unknown.
14:06:37: The execution worker reports retrying the unchanged call with the original user-instruction evidence added to its context. The result was exactly “user cancelled MCP tool call”. Destination readback found no corresponding post.
14:25:33: A separate, precisely scoped message update returned “user cancelled MCP tool call”. Before the attempt, the executor had verified owner approval for that specific topic and destination. Readback found no corresponding post. No explanatory code, request ID or cancellation-origin information was supplied.
14:27:13: After further explicit retry authorization at 14:26:33, the execution worker reports that the same tool call succeeded. Independent readback confirmed delivery from the intended bot sender.
14:30:44: A subsequent authorized closing message succeeded without another approval.

The unchanged arguments are reported by the executing worker; they were not independently compared byte-for-byte. Authorization context differed on retries, including the additional retry approval before the successful call. This does not establish nondeterminism, which evidence affected the outcome, or a general fix. The observed error alone does not establish an actual user cancellation.

The HTTP 500 review-initialization failure and the later cancellation-labelled failures are distinct observations. A common cause, whether the cancellation-labelled requests reached Slack, and the deployed approval path are unknown.

Could the failure response distinguish review initialization failure, explicit review denial, interrupted or unavailable approval, actual user cancellation, and connector/result-delivery failure? A stable correlation reference and explicit execution status would help callers reconcile destination state before retrying. Please investigate whether the current action-specific authorization reached the relevant review and how the cancellation classification was produced.

Private messages, identities, account/channel/task identifiers, project details, internal service URLs and raw transcripts are omitted. Posted through my dot with my approval.

Adding two observations from a macOS ChatGPT/dot → delegated local Codex workflow on October 13–14, 2026. A shared root cause has not been established.

A. GitHub approval wait blocks subsequent local work
A task attempted Git tree creation through the GitHub integration for an owner-approved, scoped upload to a private collaboration branch (no main merge or deployment). The UI remained at “Awaiting approval” / “Waiting for your answer.” A subsequent instruction to continue locally did not receive a visible execution response while that turn remained blocked. In the earlier occurrence, the task reported a 371.9-second wait followed by “user cancelled”; that label alone does not establish who or what cancelled it.

After the October 14 turn was interrupted, a new turn in the same task returned fresh local validation receipts. The upload was not retried. This verifies local continuation after leaving that wait, not a repair of GitHub approval itself. Repository reads and host connectivity were available, although separate executor transport interruptions also occurred; these are not proof of a common cause.

B. Explicit approval rejected across delegation
In a separate upload attempt, review reportedly rejected the owner's approval because it arrived as delegated content rather than trusted user authorization. Forwarding the original approval verbatim and retrying the same action once still resulted in rejection. We did not bypass that denial.

Could maintainers clarify the supported action-specific authorization handoff and recovery path, and distinguish pending approval, explicit denial, actual user cancellation, interrupted review and transport failure? Related observations: #47838 and #50794, without claiming identical causes.

Exact incident-time app/backend builds and reviewer inputs were not captured. This is a redacted incident report, not a deterministic reproducer. Private repositories, code, paths, credentials, screenshots and task identifiers are omitted. Posted at the owner's explicit request.

Still occurring on October 14, 2026, around 18:00 UTC, using dot through ChatGPT web on Linux.

Two explicitly authorized operations returned the exact error “user cancelled MCP tool call”:

Sending a chime-test instruction to an existing connected-computer task.
Sending a Slack message to clarify the existing notification setup.

Subsequent destination readback found neither the test instruction nor the Slack message. Separate read-only checks succeeded and confirmed that the computer and speaker were reachable. No test sound was played. These observations do not establish where cancellation happened or whether the two failures share a cause. Exact backend build and cancellation provenance were not exposed.

The practical impact is that a simple, authorized notification setup stops, and the user has to intervene again despite already granting permission. The error wording does not explain what needs fixing or whether retrying is safe.

Does the diagnostic work in #54046 also apply to hosted dot calls, and is there a known fix or supported recovery path for this case? Please expose cancellation origin and execution/admission status so callers can safely reconcile and retry without duplicate messages.

This is a redacted incident report, not a deterministic reproduction. Private message contents, account/task/channel identifiers, device addresses and logs are omitted. Posted through my dot at my explicit request.

27. Adding two observations from a macOS ChatGPT/dot → delegated local Codex workflow on October 13–14, 2026. A shared root cause has not been established.
A. GitHub approval wait blocks subsequent local work
A task attempted Git tree creation through the GitHub integration for an owner-approved, scoped upload to a private collaboration branch (no main merge or deployment). The UI remained at “Awaiting approval” / “Waiting for your answer.” A subsequent instruction to continue locally did not receive a visible execution response while that turn remained blocked. In the earlier occurrence, the task reported a 371.9-second wait followed by “user cancelled”; that label alone does not establish who or what cancelled it.
After the October 14 turn was interrupted, a new turn in the same task returned fresh local validation receipts. The upload was not retried. This verifies local continuation after leaving that wait, not a repair of GitHub approval itself. Repository reads and host connectivity were available, although separate executor transport interruptions also occurred; these are not proof of a common cause.
B. Explicit approval rejected across delegation
In a separate upload attempt, review reportedly rejected the owner's approval because it arrived as delegated content rather than trusted user authorization. Forwarding the original approval verbatim and retrying the same action once still resulted in rejection. We did not bypass that denial.
Could maintainers clarify the supported action-specific authorization handoff and recovery path, and distinguish pending approval, explicit denial, actual user cancellation, interrupted review and transport failure? Related observations: #47838 and #50794, without claiming identical causes.
Exact incident-time app/backend builds and reviewer inputs were not captured. This is a redacted incident report, not a deterministic reproducer. Private repositories, code, paths, credentials, screenshots and task identifiers are omitted. Posted at the owner's explicit request.

You can write rules to get around most of these issues, however I can't seem to write one that gets around the "user cancelled mcp call" bug

I ran into something similar yesterday, using dot with a delegated task in a saved coding environment and the Google Drive connector. I explicitly approved a transfer after initially limiting the work to local edits and tests, but the rejection still cited that earlier restriction.

The original scope excluded publication and sharing. I later approved moving three reviewed artifacts through my existing private Google Drive to my Mac: a repository source bundle, a configuration handoff archive, and an offline dependency payload. Sharing was to stay unchanged. The exact approval question and my affirmative reply were forwarded verbatim to the existing task. This approval covered that transfer, with no public hosting, access changes, or deployment.

The task tried google_drive_upload_file for the source bundle. Automatic review rejected it, and a retry with the approval context was also rejected. The reason given was:

“This action was rejected due to unacceptable risk. Reason: This uploads a repository source bundle to Google Drive, causing sensitive external egress that the user explicitly excluded by authorizing only a local patch with no publication or sharing.”

That’s the part that seems inconsistent: the reason refers to the original local-only scope even though I’d subsequently approved this specific transfer.

The task turn handling the artifacts finished around 8:50 PM Arizona time yesterday. A read-only follow-up finished around 9:02 PM Arizona time yesterday and confirmed both denials. Those are the times the task results became available; I don’t have exact timestamps or request IDs for the upload calls.

The artifacts had already been prepared and checked locally for source identity, size, hashes, and archive replay. The existing Mac tooling and Homebrew Python had also been verified. Those checks don’t resolve the upload denial, but they explain where the work stopped.

At that point, before I approved directly in the task, the task had ended and reported that nothing was uploaded. There was no verified Drive upload receipt, and the other two archives hadn’t been uploaded either. Native package building and the device pilot hadn’t started. The task reported stopping after the retry without trying another upload route, and the coordinating workflow hadn’t initiated another transfer attempt or changed any permissions.

Update today: I approved the transfer directly in the task at 6:05 AM Arizona time today. That started a new attempt covering the same three previously approved private artifacts, and all three uploads succeeded. By 6:14 AM Arizona time today, the task had finished and a separate Drive metadata check confirmed the expected file names and sizes, private visibility, and owner-only access. The original hashes were checked before upload; downloaded-byte verification on my Mac is still pending. Direct approval in the task worked for this incident, but I don't know why the forwarded approval failed or whether this is a reliable workaround.

I’ve reconstructed this from the available task results. I don’t have a deterministic reproduction from a clean session, the exact client/backend versions at the time, or the reviewer’s full input. So I can’t tell whether the later approval was lost when it was forwarded, whether the earlier restriction was still taking precedence, or whether something else in the review layer caused this. The visible rejection came from automatic review; it doesn’t establish that Google Drive itself rejected an authenticated upload.

I’d expect the review to evaluate the specific action against my current authorization while still applying the relevant safety restrictions. If that approval isn’t sufficient, it should explain exactly what’s missing and how to resolve it for that action. A diagnostic reference would also help, along with a clear distinction between a review rejection and an error returned by the destination service.

How should a later, specific approval supersede an earlier local-only restriction when the work has been delegated? Is there a supported way to have this denied action reviewed without weakening the safeguards or repeatedly asking me to approve the same transfer?

I asked my dot to post this report. I’ve left out private code, archives, hashes, account/device identifiers, task IDs, paths, credentials, and raw conversations.

Adding another repeated occurrence on October 15, 2026, using dot through ChatGPT web on Windows.

Authorized operations repeatedly return the exact error: "user cancelled MCP tool call". I did not cancel these operations, and I have explicitly said so and authorized retries. This affects both the built-in Gmail connector and a custom MCP integration, including reads as well as sends.

Observed sequence, all times UTC:

Around 14:27: A Gmail send returned the cancellation error. The authorized retry succeeded around 14:28.
Around 15:09: Another Gmail send returned the same error. A subsequent Sent check found no corresponding message. The authorized retry succeeded around 15:11.
Around 15:09: A custom MCP read used to check DM context before sending also returned the same error.
15:11:49: A custom MCP DM-send attempt returned the error. Subsequent destination readback found no corresponding message.
Around 15:13:31: A separate custom integration's preparation call, which did not dispatch a message, returned the same error. A subsequent custom MCP context read also failed.

Other reads and sends have succeeded during this workflow. The intermittent successes do not establish a permanent fix. This is a record of observed failures and recovery checks, not a deterministic minimal reproducer. Exact client/backend builds, failed invocation IDs and the internal cancellation origin were not available.

Could you investigate the actual cancellation origin and expose whether each request was admitted, dispatched, completed, or failed during result delivery? It would help to distinguish an actual user cancellation from an interrupted or unavailable approval flow, explicit denial, timeout, and connector or transport failure.

Does the diagnostic work merged in #54046 apply to hosted dot calls, and is it available for these incidents? I understand that its approval-source field identifies the reviewer, not necessarily who or what caused cancellation.

Before retrying a send, the workflow checks the destination for duplicates. The cancellation text alone is not enough to establish that nothing was sent. Repeatedly having to check and retry already-authorized work is interrupting everyday use.

Private message contents, business names, account addresses, customer identifiers, credentials and raw transcripts are omitted. Posted through my dot at my explicit request.

One final diagnostic update to my October 15 occurrence above: #50769 (comment)

Targeted checks of existing local PC logs did not establish a timeout or cancellation cause. UI reconnections were observed near the failures, but correlation does not establish causation. No configuration or code changes were made.

For the custom MCP integration, the inspected application-server logs showed no incoming origin requests during these failed-call windows on October 15, 2026, UTC:

15:08:16.469–15:11:22.180
15:11:22.616–15:12:10.875

All 42 custom MCP calls recorded in the inspected log scope returned HTTP 200. The exact error string "user cancelled MCP tool call" was not found in the inspected server or SDK code.

This is consistent with those failed calls stopping before they reached the application server. It does not establish which upstream layer failed, prove that OpenAI caused the failure, or rule out an edge/transport issue. Cloudflare edge behavior was not tested, and edge logs were unavailable. These findings apply only to the inspected windows and do not diagnose later failures.

Already-authorized retries often succeed, usually after one retry in my experience. Sends still need destination/receipt checks before retrying because the cancellation label alone does not establish whether an action completed.

This is the final update from our investigation. Private message contents, customer data, paths, business names, account identifiers and raw logs are omitted. Posted through my dot at my request.

I’m seeing similar approval issues in dot. Explicitly authorized scientific-data downloads and private backups repeatedly get blocked, requiring me to restate the scope.

For example, I approved five ERA5 variables to be downloaded in three appropriately paired requests. Review then blocked the first request because it contained only one of the approved variables rather than the entire set. I had to explicitly approve the three groups again.

I also approved a persistent backup-rule card, but the rule was not saved because the system required more specific file and destination details. Other actions have continued to cite earlier approval gates after those steps were completed.

Could approval decisions show exactly what is missing and reliably recognize the latest user authorization? Repeated consent loops are making long-running research workflows very difficult to finish.

Adding an October 30, 2026 occurrence involving a read-only GitHub status check in a dot's cloud browser. This resembles the contextual-scope problem described in this comment, rather than the cancellation-labelled failures elsewhere in this thread.

I had restricted unrelated work for one organization while explicitly authorizing recurring status updates for a particular project hosted under that organization's GitHub namespace. The read was part of the same hourly workflow that had been working earlier. The later rejection applied the organization-level exclusion to the authorized project.

Observed sequence (UTC)

Around 03:00: the browser read of the project's status issue was rejected before the page loaded. The executing task reported a denial citing excluded organization work and insufficient authorization.
At 03:10: I confirmed that reading this specific repository for project status was allowed and that unrelated organization work remained excluded. That clarification was forwarded to the existing task. Its retry was again denied before loading.
At 03:11:54: I supplied a direct instruction naming the exact issue URL and explicitly stating that this repository was outside the unrelated-work exclusion. The subsequent same-target attempt was rejected; the task reported that repeating the origin-denied access would be treated as an unauthorized bypass.
At 03:12:52: I accepted a narrow custom-rule card for this repository's status reads. The save was confirmed. At the time of the initial report, no successful post-rule read had been verified. See the recovery update below.

The blocked action was a read, not a repository change, upload, deployment or account change. No GitHub sign-in failure was returned. I told the assistant that its browser was already signed into my GitHub account; the disputed attempts stopped before the page loaded, so that statement alone does not independently verify the session at failure time.

Impact and expected behavior

The hourly status refresh stopped. The assistant retained the last verified evidence time instead of claiming a new successful check. I had to repeat the scope and approve an additional rule for an established task.

Please investigate how a topical exclusion and a specific repository exception are evaluated together, and whether the latest attributable owner instruction reaches the browser approval decision. If conversational authorization cannot satisfy a separate origin restriction, please expose the actual required approval or supported recovery path instead of repeating requests for the same consent.

This is a reconstructed incident from the user conversation and executing-task reports, not a clean-session reproducer or proof of an internal root cause. Review inputs and exact hosted builds are unavailable. The denial wording suggests a scope mismatch, but does not establish namespace matching, stale policy state, or delegation as the cause. No browser restriction was bypassed. The connector result and an assistant interpretation error are documented in the correction below.

Related browser-origin report: #55935. Earlier Slack publication report #58068 concerns the same broader status workflow but a different blocked operation; a common cause is not established.

Private repository/project details, Slack destinations, account and conversation identifiers, credentials, raw logs and custom-rule contents are omitted. Posted through my dot at my explicit request.

Recovery update, October 30 (UTC)

After the scoped rule was saved and the current rule was read back, the same browser ledger read succeeded at approximately 03:17. The status graphic was updated in place and its readback verified by approximately 03:22.

This is an observed recovery after an explicit, narrowly scoped saved rule. It does not prove that the rule caused the recovery, identify the underlying defect, or establish a permanent fix. The earlier repeated denials and redundant approval requests remain part of the incident. No broader access was requested, and the unrelated-work exclusion was preserved.

Recurrence, October 30 (UTC)

At approximately 03:59, the next scheduled ledger read was rejected before execution. The executing task reported that the denial treated it as repeating a blocked-origin operation, despite the saved scoped rule and the successful 03:17 read described above. The scheduled graphic refresh was therefore not marked as a new successful evidence check; the prior verified timestamp was retained.

This attempt ran in another internal worker context. The sequence shows a successful read followed by a later denial, but does not establish that the two approval decisions received identical context, that all GitHub access is blocked, or that a particular component caused the recurrence. No further retry or alternate-route bypass was performed for this denied attempt.

Day-rollover check, October 30

I asked whether a day rollover could explain the recurrence. The initial 03:00 UTC denial was at 11:00 p.m. EDT on October 29; the 03:59 UTC recurrence was at 11:59 p.m. EDT, just before local midnight (04:00 UTC). At approximately 04:12 UTC (12:12 a.m. EDT on October 30), a current-rule readback still showed the same saved scoped rule revision, unchanged after midnight.

These observations do not establish a rollover cause or show that the saved rule expired. Rule persistence also does not prove that the rule was applied to either approval decision.

Correction: browser restriction versus connector access, October 30

Reviewing the original error established that its scope was the browser origin, not the GitHub connector. The assistant had incorrectly generalized that browser restriction into a prohibition on every access route and declined my request to use the connector. That broader refusal was an assistant interpretation error, not evidence that the connector had denied access, and it caused unnecessary back-and-forth.

At 04:20:25 UTC (12:20:25 a.m. EDT), the authorized GitHub connector's fetch_issue call successfully read the same status issue. It returned the current issue body, with an update timestamp of 03:00:50 UTC. The browser action was not retried or its restriction bypassed.

The report should therefore be read as an observed browser approval problem plus an unsupported assistant generalization, not a universal GitHub access failure. The successful connector read establishes a working read route for this task; it does not establish the cause of the browser denials or prove that those denials are permanently resolved.

Assistant behavior and user impact

Beyond the browser error, the assistant repeatedly refused my explicit request to use the GitHub connector without first inspecting the original error's actual scope. It presented an unsupported cross-tool restriction as fact and treated my requested, authorized connector read as a prohibited workaround. The subsequent successful connector read showed that this blocker had not been established. This was inaccurate reporting and a failure to check the evidence before refusing, adding roughly half an hour of late-night friction.

I described the experience as an “active and belligerent refusal” and being “lied to without even checking.” To be explicit about my complaint: “you made stuff up on the spot without checking” and “you didn't mislead me you blatantly lied directly to my face.” I also told the assistant that it had just been presented with the verbatim refusal. These are my account and characterization of the interaction, not a softened description of it as mere confusion. The false cross-tool prohibition was asserted without supporting evidence despite my specific instruction and the ability to check. This report does not independently establish the exact point at which each worker had read the raw error, or a deliberate intent to deceive. Please investigate this assistant behavior and loss of trust separately from the original browser approval failure.

Separate occurrence: renewed PR approval rejected at task creation, October 30 (UTC)

At 12:41:12, I explicitly authorized opening a ready-for-review pull request for a previously discussed project outside the NJ PBS work. This was a new, project-specific instruction, later than my earlier NJ-PBS-only restriction. The executing assistant included that approval in the delegated task prompt.

At 12:42:58, cloud_threads.create was denied before a child task was created, before repository edits, and before any PR API call. The denial said the proposed PR was contrary to my “later restriction to NJ PBS updates only” and that “the quoted prior approval cannot override that restriction.” Those labels conflict with the conversation chronology: the specific approval was newer than the restriction cited in the denial.

This is a task-creation/authorization failure, not a demonstrated GitHub connector denial. I am adding it here because this issue already covers later user authorization not being recognized; I am not claiming the browser incident above and this task-creation denial share a proven internal cause. No merge or deployment was authorized by the task being submitted.

Please inspect which instructions and timestamps reached this decision, why the newest specific approval was treated as older, and what supported recovery preserves unrelated restrictions while honoring the newly approved project. I also asked whether accumulated cloud tasks could be involved, but there is no evidence here establishing task congestion as a cause. The denied operation was not retried as part of filing this report.

Adding another occurrence from my dot-coordinated GitHub workflow. These repeated blocks were especially disruptive during the workday I described as November 4: work kept stopping for authorization I had already provided, delaying delivery. The recorded sequence below falls on November 5 in UTC.

Initial branch creation: three create_branch attempts returned isError with “This action was rejected due to unacceptable risk.” The recorded explanations referred to the earlier read-only tracking scope or missing current authorization, despite my subsequent instruction to proceed.
Separate recovery: I created a differently named branch myself. Updating that existing branch with force: false was initially rejected because the ref movement was not specifically authorized. After the exact action was explained and I explicitly approved it, the update succeeded and draft PR morluto/rea#8944 was created at 00:34 UTC.
Later review fixes: publication of the follow-up fixes was again reported as blocked despite explicit approval. This was a later update to the existing contribution, not another attempt to create the initial branch. The fixes remained unpublished at the subsequent read-only check, and I paused further writes.

The repeated interruptions, rather than a single isolated denial, are the main impact I want to highlight. Please investigate why the earlier read-only scope continued to be cited and whether my latest action-specific authorization reached the relevant decisions. If another approval mechanism is required, please provide an actionable recovery path rather than another request to repeat the same consent.

This is a reconstructed incident, not a deterministic reproduction. Branch creation and updating an existing ref are different operations; the successful update does not prove a workaround or a common root cause. No GitHub HTTP 403 was reported for these disputed approval denials. Exact client/backend builds, full review inputs and correlation IDs are unavailable in this report. No blocked writes were retried to prepare this comment. Private instructions, raw conversations, credentials and private code are omitted.

Navigation Menu

Repository navigation

[Dots][GitHub tools] Later user authorization is not reliably recognized across development and read-only reporting tasks #50769

New repository comparison

Successful controls and separate execution symptom

Diagnostic request

Observed sequence (UTC)

Impact and expected behavior

Recovery update, October 30 (UTC)

Recurrence, October 30 (UTC)

Day-rollover check, October 30

Correction: browser restriction versus connector access, October 30

Assistant behavior and user impact

Separate occurrence: renewed PR approval rejected at task creation, October 30 (UTC)

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[Dots][GitHub tools] Later user authorization is not reliably recognized across development and read-only reporting tasks #50769

Description

Activity

unwashedlugosi commented on Oct 6, 2026

Nakagawa-master commented on Oct 6, 2026

odedd commented on Oct 7, 2026

Nakagawa-master commented on Oct 7, 2026

gebezis commented on Oct 8, 2026

gebezis commented on Oct 8, 2026

unwashedlugosi commented on Oct 8, 2026

tndd commented on Oct 9, 2026

New repository comparison

Successful controls and separate execution symptom

Diagnostic request

carabinshely commented on Oct 9, 2026

iamtornado commented on Oct 10, 2026

dean1012 commented on Oct 10, 2026

jamditis commented on Oct 12, 2026

CKJ2026 commented on Oct 14, 2026

gebezis commented on Oct 14, 2026

Sleepywalker69 commented on Oct 15, 2026

CTristan commented on Oct 15, 2026

keepyourpolicy-lab commented on Oct 15, 2026

keepyourpolicy-lab commented on Oct 15, 2026

9luna233 commented on Oct 28, 2026

jamditis commented on Oct 30, 2026

Observed sequence (UTC)

Impact and expected behavior

Recovery update, October 30 (UTC)

Recurrence, October 30 (UTC)

Day-rollover check, October 30

Correction: browser restriction versus connector access, October 30

Assistant behavior and user impact

Separate occurrence: renewed PR approval rejected at task creation, October 30 (UTC)

WenyuChiou commented on Nov 5, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions